[Openid-specs-mobile-profile] Introduction of IAL

[Hjelm, Bjorn]

Michael,
Though attribute assertion isn’t precluded from NIST SP 800-63A, IAL refers to the identity proofing process (and the “requirements by which applicants can both identity proof and enroll”) and the results rather than individual attributes.

In the iGov WG, we had discussed how to support NISTIR 8112 Attribute Metadata<https://csrc.nist.gov/publications/detail/nistir/8112/final> as a schema for attributes that may be asserted about an individual. Similarly, Torsten (Lodderstedt) made proposal at the last IIW for Identity Proofing with OpenID<https://iiw.idcommons.net/Identity_Proofing_w/Open_ID> using claims and confidence levels (that’ll probably become a work item in the Connect WG as the use cases span multiple WGs).

I personally like Torsten’s proposal but would prefer that it aligns with NISTIR 8112. I think this is a better approach rather than what you’ve proposed.

BR,
Bjorn

From: Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] On Behalf Of Engan, Michael
Sent: Thursday, January 31, 2019 8:26 PM
To: openid-specs-mobile-profile at lists.openid.net
Subject: [E] [Openid-specs-mobile-profile] Introduction of IAL

Good evening,

Has anyone looked at the rollout of IAL on their Attributes? I am looking at it for the US carriers and wanted feedback. Genericly we want to align to the NIST definitions.
Ial1: self asserted
Ial2: IDP has verified
Ial3: trained human has verified with government issued id.


We have two main approaches we are contemplating, but I would be open to others if anyone in the community has looked into it.
Approach 1

Approach 2

“sub”:”<mccmnc-(salted for this SP)>”,
    “name”: {
        “name”:”Jane Doe”,
        “given_name”: “Jane”,
        “family_name”: “Doe”,
        “ial”:1 },
   “birthdate”: {
        “birthdate”:”0000-03-22”,
        “ial”:1},
   “email”:{
        “email: “janedoe at example.com<mailto:janedoe at example.com>”,
         “email_validated”:”true”,
        “ial”:2 }
   “gender”:{
        “gender”:”xxx”,
        “ial”:1 }
    “profile_photo”:https://www.....<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.....&d=DwMGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=NMZJHCV8pjvGIH2fTx9z6tOf9bN5lnuu0jl9p1INnD0&m=Pr1pScWDPd67MnNh17JcdV6PC0EInxlFPn3SH9NJBJ0&s=eQ8IzerVqaVZdRB8q8Bw-0IMnjp-e1_H4I5BGyaaAg0&e=>,
    “location”:{
        "lat":"xxxxxx",
        "long":"yyyyyy",
        "alt":"zzzzzzzzzz",
        "acc":"accuracy",
        "speed":"cccccccc"
    “address”: {
        “street_address”: “1234 Hollywood Blvd.\naddress line 2”,
        “locality”: “Los Angeles”,
         “region”: “CA”,
         “postal_code”: “90210-3456”,
        “country”: “US”,
        “ial”:2},
   “postal_code”: {
        “postal_code”:“90210-3456”,
        “ial”:2 }
   “phone_number”: {
        “phone_number”:“+13101234567”,
       “phone_validated”:”true”,
        “ial”:3 }
  }


myData = {
                "name":"Jane Doe",
                "given_name":"Jane Doe",
                "family_name":"Jane Doe",
                "birthdate":"Jane Doe",
                "phone_number":"9132848814",
                "email":"ptdecker at mac.com<mailto:ptdecker at mac.com>",
                "ial2":["name","email"],
                "ial3":["phone_number"]
};



In this approach each attribute gains sub elements.  It greatly increases the size. And makes some access odd.  Like  $name=$data.name.name…

In this approach the data seems more compressed, but does not seem right either.   It also may make it harder to hold other attributes like the last validated time stamp, or last edited timestamp per attribute for more verbose internal access.

Note; email_validated and phone_validated came from Core spec, and with IAL we could/should drop them completely.






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20190201/9febe3bf/attachment-0001.html>