Home

Welcome to the OpenID-Connect-PHP wiki!

Email from Dazza to Club MED UMKC Law Team 3-06-2015:

Hi Evan and Paul,

I was working with Michael Robak today on the upcoming UMKC events and realized I hadn't checked in with you on your OpenID Connect project for a long time. How is it going?

If you haven't already come across the way OIDC defines "standard claims" for a core set of identify attributes, you will want to take a close look at the attached excerpt from the formal specification. One thing OIDC does very well is standardize this core set of identity data (not only the syntax but also how to discover, interrogate and share them). This means the confusing and non-interoperable variety of ways departments assign or accept account holder identifiers, names, address fields, etc would finally have a base-line common reference and each account holder could readily re-use their same standard identity attributes with any OIDC compliant app, service or other system.

Permission management for access to each one and every combination of these protected personal data resources is easily granted under defined OAuth 2 "scopes" and can just as easily be reviewed and revoked by the individual later.

I tried to address the questions about the type of information OIDC systems store or manage for users in the wiki page where it was presented. It is conceptually best to just start with two user cases until each role, relationship, function and transaction or data flow is clearly understood and easily explained: 1. The basic unified login flows and 2. The individual grant of permission to access additional OIDC standard claims identity attribute data over and above the attributes needed solely to login (the OpenID string, email string, related token, etc).

Once you can reliably and repeatedly name the role and flows of each player engaged in those two scenarios it is possible to start addressing and decomposing more complex scenarios with additional and non-standard types of protected data or other resources held and managed by distributed third parties integrated through webs of interlateral agreed services and overarching participating in cross-boundary trusted provider networks. It is more complex but very understandable once the fundamental flows are absorbed.

If it's allowed under the rules of the class or maybe as part of the PrototypeJam #2 I'd like to show you guys how to create a specially tailored OIDC service configuration that is specifically to ensure the business, legal and technical aspects of each parties roles, relationships and exchanges precisely line up. This means more effective, predictable and efficient transactions and holistic basis for assessing performance and outcomes and other success metrics for the systems that apply this approach. I call it "IAuth". I suspect it would make a good basis for telling the story you both most seem to wish to tel.

Thanks,

• Dazza

Email From Dazza Greenwood to Evan Absher on what the breakdown is for use cases 3-07-2015:

Sure - the use case is:

1. Login. Use OIDC enabled account to login.
2. Authorize access to more PII using OIDC enabled account. To make it as easy and direct as possible just make that extra PII Data some standard OIDC claims.

Confused still? If so then make one chance to the above. Take out OIDC. Just assume OAuth 2.

Confused by that too? If so, take out OAuth 2 (by name) and replace with "Google".

Like this:

"1. Login. Use Google enabled account to login. 2. Authorize access to more PII using Google enabled account. To make it as easy and direct as possible just make that extra PII Data some standard OIDC claims. "

Ie. Log into nyt with google. Later authorize google to access some Google plus profile data like your profile URL to list on a nyt profile. Or your friends in circles. Pretend friends in circles in standard claims data.

Please add this and prior email from last night to the github wiki somewhere (on bottom of page maybe) to keep context.

Email from Dazza 4-8-2015

Hi Evan,

Where is this written? Pray-tell in the GitHub repo? Could you send a link?

To make this simple, try mapping out the interactions between each party, noting the names role consistently through the transaction flow like this:

1. First map it out just with a "click to auth" for "login" bare minimum data only (assume that is an auth and access token, and the username and email attributes as only PII or Personally Linked data exchanged; then
2. Second, map out the exchange like above EXCEPT make the "click to auth" include BOTH the login data attributes PLUS the rest of the OIDC "Standard Claims" (just scan each of them claim, the profile url, the phone number, address, etc) and note what is to be exchanged. Assume for both 1 and 2 above that the IdP hold all the data for login and standard claims data to keep it simple. Now, notice how the contract clauses and the words in the OAuth 2 scope and corresponding 'click this button to authorize access to your protected data resources" language can reasonably be expected to be somewhat different depending on if it just covers case #1 or also needs to cover case #2.
3. NOW - assume a SECOND BUTTON to auth a different scope of access called "Your Personal Data Record XYZ" or some such, and postulate it is the criminal records (as you did in class) as a start and further assum the data is in the form of a BLOB (binary large object) like a PDF or MS Word file and not individually machine readable data fields in a structured format such as you have with OIDC login and other standard claims identity attribute date. To make this easy to "get" just think of times when you approve access to a drop box folder to share out a file in dropbox with another service or if you share an Evernote folder or file or if you share a photo or any other service that lets you share any BLOB. Go Google the web for 5 seconds to find some examples if you can't think of them and just note that this scope is NOT LIKE the first two and it can not be precisely fit to the data.... or I should say the way OAuth 2 is implemented today this is not the common practice because it complicates the intended use and purpose of providers of large-scale multi-purpose and transaction-context neutral services. So, just think: what if this file was NOT held by the IdP and instead was held by MeBox or SecureBox or something just like drop box EXCEPT your team gets to write the OAuth 2 Scope for granting access any way you want (eg you can narrowly tailored the scope to only authorize the third party client to access under a particular TECHNICAL CONSTRAINTS such as a single file and date type in a single directory of a single storage location and further postulate the OAuth 2 Scope operates according to a particular set of LEGAL CONSTRAINTS contained solely in the contracts among the three parties (the individual account-holder, the system provider and the third-party app provider ... aka the "iron triangle" formation that underlies the basic but brilliant new capability afforded by OAuth 2 and downstream innovations like OIDC, UMA, etc).

the tech scope would be constrained to only enable access by the

In this case just mentioned, the legal contracts would need to specify that this scope only applies to XYZ file, right? The answer is "yes". Playing it through, the tech scope would be constrained to only enable access by the third party app to that one file held by the system provider - eg if the city is the main "system provider" in the context of this use case and, say, dropbox or mebox etc is the "third party app" provider operating on behalf of a commercial jobs program, then maybe the scope allows the user to auth the app to access and grab a copy of a criminal record held by the agency based on explicit consent and in this case, the data is non-standard and considered just a big fat BLOG to keep it tied to the most common patterns of use and very simple.

The point of just drawing out each party using the business and technical and legal roles is to be able to play out each scenario and not get anomalous results or miss key variations of likely transactions flows that will happen. To take advantage of this feature of the BLT method, just play the scenario out by reversing the City and the Third Party App roles like this: Turn the access right the other way around, and the third party provider for instance enables a person to hold a criminal record or health record etc and to authorize access for the city as part of hiring or vetting or something like that.) - or if the context is the other way around then the Note what the user would see on the screen and in 1 and 2 and highlight how it should be different and do the same for the corresponding contract language in the user agreement with the IdP and the other agreements (there are

More later. Out of time. Thanks!