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

Torsten Lodderstedt torsten at lodderstedt.net
Sun Feb 3 11:59:35 UTC 2019


> 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.).

I think it depends on your use cases. In our case, the recipient needs data about the method and the evidences gathered (e.g. ID Card number and issuer) to comply with legal requirements.

To give you an example:
We use this approach to provide identity data for the creation of qualified electronic signatures according to eIDAS. In this case, the respective service Provider (the so-called Qualified Trusted Service Provider) is obliged by law to obtain and retain this data to document the process and to be able to trace back to the origin of the identity data in case of a dispute or an audit.

Our approach has been officially certified to fulfill the eIDAS requirements based on bank KCY data and is being rolled out now.

I would also like to point out that the representation I have shown at IIW allows to express compliance to a certain trust framework and level. We right now don’t use this since our data is maintained according to the local anti money laundering law, which does not distinguish different levels.

> Furthermore, we have the potential challenge that we have multiple proofing methods. In my sample alone I see at least 5 different proofing sources.
> 	• Aka sim authentication as proofing   : phone number
> 	• Government id as proofing : name, address, birthdate  (in person vs digital capture)
> 	• OTP as proofing : email
> 	• Network identity : location derived from cellular routing. (vs self claimed when leveraging WiFi)
> 	• Self claimed attributes : photo, gender, …   (or perhaps verified in person by retail rep).

The question is what you are aiming for. When we started the work, we also aimed at providing assurance metadata for all claims in an ID Token or User Info Response. In the course of the work I realized that different claims require different methods and (in the end) trust frameworks. Also your examples show that email addresses and person data are proven quite differently. Covering all possible variations while fulfilling hard legal requirements would most likely result in a quite complex and generic representation.

That’s why we decided to cut the scope down to the bare minimum required to fulfill our business requirements:
- we focus on person data only (name, date of birth, place of birth, ...) 
- the solution covers verified data only as self asserted claim are already covered by OIDC
- the approach allows to attest verified and none verified claims in the same response  
- we tried to use existing OIDC claims for identify proofing while (structurally) ensuring developers cannot interpret none-verified claims as verified claims
- we use the existing OIDC representation of verification metadata for email and phone number as it suffices for our purposes 

I don’t claim (or think) our approach is the only way to go. I basically wanted to provide you with more context how and why we arrived where we are now. Having said that, I would be very interested to work towards a joined proposal with you guys. If you want I would share the specification document I‘have prepared for submission to the OpenID working group with you.

I‘m fully aware of the fact our approach is only battle proven in the context of German & EU jurisdictions. I‘m not an expert in ID proofing in the US but since there is neither an ID card nor a central inhabitants registry, it must work differently. So extending the current proposal to cover the requirements of more jurisdictions is key for an international standard.

If you agree with my arguments for keeping the scope as narrow as possible, I would suggest to work towards two extensions: one for person identity proofing and another one for network data assurance.

kind regards, 

> 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 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 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”,
>          “email_validated”:”true”,
>         “ial”:2 }
>    “gender”:{
>         “gender”:”xxx”,
>         “ial”:1 }
>     “profile_photo”:https://www.....,
>     “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",
>                 "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 --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3711 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20190203/6b0e420c/attachment.p7s>

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