Skip to content

Home

Jump to bottom Edit New page
EvanAbsher edited this page Apr 7, 2015 · 4 revisions

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.

USE CASES FOR THE PROTOTYPE JAM APRIL 24th AND 25th

The two use cases below are meant to illustrate OIDC architecture when the IdP is a private entity and the City is the Client and also if the City is a IdP providing authorization for a more traditional web Client, say a start-up company participating in the Cisco KCMO living labs initiative.

Login Flow Use Case for Municipal Digital Service to End-User Use Case:

Roles End-User City Resident seeking to sing into a “Municipal Digital Service.” Municipal Digital Service (“MDS”) Universal, Persistent Login that Incorporates all City Services. Identity Provider (“IdP”) In this use case it would be Google, Facebook, Bing, Twitter, etc. Houses both the Authorization Server and the Resource Server Authorization Server provides the authenticating power Resource Server houses the data the End-User has “stored” Action User wants to login into the City Digital Service without using a password and have persistent information retained over the course of time, different transactions and departments. City wants to alleviate the burden of housing secured data, ie passwords etc. Also the city wants all MDS to work with more interoperability. Data End-User/Resident Standard Claims for basic log-in to City Subject ID Name Locale Phone Number Physical Address Email Address Gender Client/MDS Flow for Login MDS Prepares an Authorization Request Containing the following request parameters. Standard Claims for basic log-in to City Subject Name Nickname Preferred User Name Locale Phone Number Physical Address Email Address Gender Birthdate MDS sends request to Authorization Server Authorization Server Authenticates the End-User Sub ID Data: Sub Type: String Description: Subject-Identifier for the End-User at the Issuer Name - William Evan Absher, Esq. Data: Name Type: String Description: End-User's full name in displayable form including all name parts, possibly including titles and suffixes, ordered according to the End-User's locale and preferences. Nickname - Evan Data: Nickname Type: String Description: Casual name of the End-User that may or may not be the same as the given_name. For instance, a nickname value of Mike might be returned alongside a given_name value of Michael. Preferred User Name - @lawgod Data: Prefered User name Type: String Description: Shorthand name by which the End-User wishes to be referred to at the RP, such as janedoe or j.doe. This value MAY be any valid JSON string including special characters such as @, /, or whitespace. The RP MUST NOT rely upon this value being unique, as discussed in Section 5.7. Locale - West Bottoms, Kansas City, Mo U.S. Data: Relative Geographic Location Type: String Description: End-User's locale, represented as a BCP47 [RFC5646] language tag. This is typically an ISO 639-1 Alpha-2 [ISO639‑1] language code in lowercase and an ISO 3166-1 Alpha-2 [ISO3166‑1] country code in uppercase, separated by a dash. For example, en-US or fr-CA. As a compatibility note, some implementations have used an underscore as the separator rather than a dash, for example, en_US; Relying Parties MAY choose to accept this locale syntax as well. Also since the municipality is the client it could be possible to implement ‘neighborhood’ type localities. Possibly even council districts. Phone number - 816-789-9090 Data: Phone Number Type: String Description: End-User's preferred telephone number. E.164 [E.164] is RECOMMENDED as the format of this Claim, for example, +1 (425) 555-1212 or +56 (2) 687 2400. If the phone number contains an extension, it is RECOMMENDED that the extension be represented using the RFC 3966 [RFC3966] extension syntax, for example, +1 (604) 555-1234;ext=5678. Data: Phone Number Verification Type: Boolean Description: True if the End-User's phone number has been verified; otherwise false. When this Claim Value is true, this means that the OP took affirmative steps to ensure that this phone number was controlled by the End-User at the time the verification was performed. The means by which a phone number is verified is context-specific, and dependent upon the trust framework or contractual agreements within which the parties are operating. When true, the phone_number Claim MUST be in E.164 format and any extensions MUST be represented in RFC 3966 format. Physical Address - 1308 w 11th St, Kansas City, Mo 64101 Data: Physical Address Type: JSON Object Description: End-User's preferred postal address. The value of the address member is a JSON [RFC4627] structure containing some or all of the members defined in Section 5.1.1. Email - [email protected] Data: email address Type: String Description: End-User's preferred e-mail address. Its value MUST conform to the RFC 5322 [RFC5322] addr-spec syntax. The RP MUST NOT rely upon this value being unique, as discussed in Section 5.7. Data: Email Verified Type: Boolean Description: True if the End-User's email address has been verified; otherwise false. When this Claim Value is true, this means that the OP took affirmative steps to ensure that this e-mail address was controlled by the End-User at the time the verification was performed. The means by which an e-mail address is verified is context-specific, and dependent upon the trust framework or contractual agreements within which the parties are operating. Gender - male Data: Gender Type: String Description: End-User's gender. Values defined by this specification are female and male. Other values MAY be used when neither of the defined values are applicable. Birthdate - 12/25/1983 Data: Birthdate Type: String Description:End-User's birthday, represented as an ISO 8601:2004 [ISO8601‑2004] YYYY-MM-DD format. The year MAY be 0000, indicating that it is omitted. To represent only the year, YYYY format is allowed. Note that depending on the underlying platform's date related function, providing just year can result in varying month and day, so the implementers need to take this factor into account to correctly process the dates. Authorization server obtains End-User Consent/Authorization Authorization server sends the end-user back to the MDS with Authorization Code MDSt requests a response using the Authorization Code at the Token Endpoint. MDS receives a response that contains an ID Token and Access Token in the response body. MDS validates the ID token and retrieves the End-User's Subject Identifier.

Login Flow Use Case for Municipal IdP for Third-Party Relying Parties to End-User Use Case:

Roles End-User City Resident seeking to sing into a “Municipal Digital Service.” Client, ala Google or Smart Cities Company Desires access to End-User account, but might be an untrusted party. This could still be an MDS, these two use cases are not mutually exclusive in this regard. The City could both be the IdP Municipal IdP Universal, Persistent Login that Incorporates all City Services. Houses both the Authorization Server and the Resource Server Authorization Server provides the authenticating power Resource Server houses the data the End-User has “stored” PRovides this service either directly through a City department or enterprise, ala Water Department, or as a pseudo-utility through a regulated private company. Action User wants to login into the City Digital Service without using a password and have persistent information retained over the course of time, different transactions and departments. City wants to alleviate the burden of housing secured data, ie passwords etc. Also the city wants all MDS to work with more interoperability. Data End-User/Resident Standard Claims for basic log-in to City Subject ID Name Locale Phone Number Physical Address Email Address Gender Client/MDS Flow for Login Client Prepares an Authorization Request Containing the following request parameters. Standard Claims for basic log-in to City Subject Name Nickname Preferred User Name Locale Phone Number Physical Address Email Address Gender Birthdate Client sends request to Authorization Server Authorization Server Authenticates the End-User Sub ID Data: Sub Type: String Description: Subject-Identifier for the End-User at the Issuer Name - William Evan Absher, Esq. Data: Name Type: String Description: End-User's full name in displayable form including all name parts, possibly including titles and suffixes, ordered according to the End-User's locale and preferences. Nickname - Evan Data: Nickname Type: String Description: Casual name of the End-User that may or may not be the same as the given_name. For instance, a nickname value of Mike might be returned alongside a given_name value of Michael. Preferred User Name - @lawgod Data: Prefered User name Type: String Description: Shorthand name by which the End-User wishes to be referred to at the RP, such as janedoe or j.doe. This value MAY be any valid JSON string including special characters such as @, /, or whitespace. The RP MUST NOT rely upon this value being unique, as discussed in Section 5.7. Locale - West Bottoms, Kansas City, Mo U.S. Data: Relative Geographic Location Type: String Description: End-User's locale, represented as a BCP47 [RFC5646] language tag. This is typically an ISO 639-1 Alpha-2 [ISO639‑1] language code in lowercase and an ISO 3166-1 Alpha-2 [ISO3166‑1] country code in uppercase, separated by a dash. For example, en-US or fr-CA. As a compatibility note, some implementations have used an underscore as the separator rather than a dash, for example, en_US; Relying Parties MAY choose to accept this locale syntax as well. Also since the municipality is the client it could be possible to implement ‘neighborhood’ type localities. Possibly even council districts. Phone number - 816-789-9090 Data: Phone Number Type: String Description: End-User's preferred telephone number. E.164 [E.164] is RECOMMENDED as the format of this Claim, for example, +1 (425) 555-1212 or +56 (2) 687 2400. If the phone number contains an extension, it is RECOMMENDED that the extension be represented using the RFC 3966 [RFC3966] extension syntax, for example, +1 (604) 555-1234;ext=5678. Data: Phone Number Verification Type: Boolean Description: True if the End-User's phone number has been verified; otherwise false. When this Claim Value is true, this means that the OP took affirmative steps to ensure that this phone number was controlled by the End-User at the time the verification was performed. The means by which a phone number is verified is context-specific, and dependent upon the trust framework or contractual agreements within which the parties are operating. When true, the phone_number Claim MUST be in E.164 format and any extensions MUST be represented in RFC 3966 format. Physical Address - 1308 w 11th St, Kansas City, Mo 64101 Data: Physical Address Type: JSON Object Description: End-User's preferred postal address. The value of the address member is a JSON [RFC4627] structure containing some or all of the members defined in Section 5.1.1. Email - [email protected] Data: email address Type: String Description: End-User's preferred e-mail address. Its value MUST conform to the RFC 5322 [RFC5322] addr-spec syntax. The RP MUST NOT rely upon this value being unique, as discussed in Section 5.7. Data: Email Verified Type: Boolean Description: True if the End-User's email address has been verified; otherwise false. When this Claim Value is true, this means that the OP took affirmative steps to ensure that this e-mail address was controlled by the End-User at the time the verification was performed. The means by which an e-mail address is verified is context-specific, and dependent upon the trust framework or contractual agreements within which the parties are operating. Gender - male Data: Gender Type: String Description: End-User's gender. Values defined by this specification are female and male. Other values MAY be used when neither of the defined values are applicable. Birthdate - 12/25/1983 Data: Birthdate Type: String Description:End-User's birthday, represented as an ISO 8601:2004 [ISO8601‑2004] YYYY-MM-DD format. The year MAY be 0000, indicating that it is omitted. To represent only the year, YYYY format is allowed. Note that depending on the underlying platform's date related function, providing just year can result in varying month and day, so the implementers need to take this factor into account to correctly process the dates. Authorization server obtains End-User Consent/Authorization Authorization server sends the end-user back to the Client with Authorization Code Clien requests a response using the Authorization Code at the Token Endpoint. Client receives a response that contains an ID Token and Access Token in the response body. Client validates the ID token and retrieves the End-User's Subject Identifier.

Add a custom footer
Add a custom sidebar
Clone this wiki locally