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

Paul Grassi pgrassi at easydynamics.com
Tue Feb 5 15:45:47 UTC 2019


Sorry all I have to miss again today. SSA ssn verification API is coming soon. May be an igov implementation :)

Get Outlook for iOS<https://aka.ms/o0ukef>

________________________________
From: Hjelm, Bjorn <bjorn.hjelm at verizonwireless.com>
Sent: Tuesday, February 5, 2019 12:32 AM
To: openid-specs-igov at lists.openid.net; Engan, Michael; Paul Grassi; openid at justin.richer.org
Cc: openid-specs-mobile-profile at lists.openid.net; John Bradley (ve7jtb at ve7jtb.com); Torsten Lodderstedt
Subject: RE: Introduction of IAL

Expanding this discussion to iGov as it relates to NIST SP 800-63A.

BR,
Bjorn

From: Engan, Michael [mailto:Michael.Engan1 at T-Mobile.com]
Sent: Saturday, February 02, 2019 9:06 PM
To: Hjelm, Bjorn; openid-specs-mobile-profile at lists.openid.net; Paul Grassi; Torsten Lodderstedt
Cc: John Bradley (ve7jtb at ve7jtb.com)
Subject: [E] Re: Introduction of IAL

Hmm. I took a look through Torstens content, and it looks like a good way to communicate the Method used for the proofing. But in my case I am looking to communicate the Level of proofing achieved, not the specific sources.  (I don’t think we would want right now to communicate the proofing sources, even though that data may be stored within each carrier.).

Furthermore, we have the potential challenge that we have multiple proofing methods. In my sample alone I see at least 5 different proofing sources.


  1.  Aka sim authentication as proofing   : phone number
  2.  Government id as proofing : name, address, birthdate  (in person vs digital capture)
  3.  OTP as proofing : email
  4.  Network identity : location derived from cellular routing. (vs self claimed when leveraging WiFi)
  5.  Self claimed attributes : photo, gender, …   (or perhaps verified in person by retail rep).



From: Bjorn Hjelm <Bjorn.Hjelm at VerizonWireless.com>
Date: Friday, February 1, 2019 at 12:18 PM
To: "Engan, Michael" <Michael.Engan1 at T-Mobile.com>, "openid-specs-mobile-profile at lists.openid.net" <openid-specs-mobile-profile at lists.openid.net>, Paul Grassi <pgrassi at easydynamics.com>, Torsten Lodderstedt <torsten at lodderstedt.net>
Cc: "John Bradley (ve7jtb at ve7jtb.com)" <ve7jtb at ve7jtb.com>
Subject: RE: Introduction of IAL

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://urldefense.proofpoint.com/v2/url?u=https-3A__csrc.nist.gov_publications_detail_nistir_8112_final&d=DwMGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=NMZJHCV8pjvGIH2fTx9z6l7g7-V-a2xW7ISf9uHdz0A&m=Y_FWe8PN4S5yARD3L0OZ0Vt74n4du3IghRo6l-Raad4&s=iRbbwujMbRXTw4XQCAGmLDQPXwanoz4dalkAIAEae4w&e=> 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://urldefense.proofpoint.com/v2/url?u=https-3A__iiw.idcommons.net_Identity-5FProofing-5Fw_Open-5FID&d=DwMGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=NMZJHCV8pjvGIH2fTx9z6l7g7-V-a2xW7ISf9uHdz0A&m=Y_FWe8PN4S5yARD3L0OZ0Vt74n4du3IghRo6l-Raad4&s=SMcHNmDyb92P4Zfs_OIiklBoObPdGxBOHRuRXrw5xS0&e=> 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/20190205/dfe9464f/attachment-0001.html>


More information about the Openid-specs-mobile-profile mailing list