Home

Welcome to the OpenID-Connect-PHP wiki!

SE CASES: Resident and Municipality, Login Flow and

[THIS IS JUST EVAN LEARNING THE CONCEPTS]

1. Liquor License
   1. Roles
      1. Applicant
         1. Person
            1. See attached OICD Standards
            2. Birthdate
            3. Data: Birthdate
            4. Type: String
            5. Description: End-User’s Birthdate
            6. Aged 18- 20 years
               1. Data: Birthdate
               2. Type: Boolean
               3. Description: True if End-User has aged 18 years, but less than 20 years, otherwise false. This means the OP has taken affirmative steps to verify against another URI that the End-User has aged between 18-20 years.
            7. Aged 21 years
               1. Data: Birthdate
               2. Type: Boolean
               3. Description: True if the End-User has aged 21+ years, otherwise False. This means the OP has taken affirmative steps to verify against another URI that the End-User has aged 21 years.
            8. Resident of Kansas City
               1. Locale, See attached OICD Standards
            9. Non-Felon
               1. Data: Felon Status
               2. Type: boolean
               3. Description: False if End-User’s felon status has been verified as non-felon, True if there End-User’s felon status is verified as felon; otherwise False. When this claim is True it means that the End-User provided necessary data to establish felon status and the OP took affirmative measures to confirm the data against other URIs.
         2. Payment
      2. Regulated Industries in KCMO 1.

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.