[openid-specs-rande] RAF expression in OIDC

Tue Sep 3 06:54:29 UTC 2019

Hi all, 

I would like to bring to your attention some ongoing work in the Connect/AB working group towards an OpenID Connect extension for identity assurance. 

Here is the link to the current draft: https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html

I think it could be utilised in your context. 

Based on the description given at https://wiki.refeds.org/display/ASS/REFEDS+Assurance+Framework+ver+1.0 I produced the following example using the definitions given in openid-connect-4-identity-assurance-1_0:

{  
   "verified_claims":{  
      "verification":{  
         "trust_framework":"https://refeds.org/assurance/profile/cappuccino",
         "eduperson_assurance":[  
            "https://refeds.org/assurance/ATP/ePA-1d",
            "https://refeds.org/assurance/IAP/medium",
            "https://refeds.org/assurance/ID/eppn-unique-no-reassign"
         ]
      },
      "claims":{  
         "given_name":"Max",
         "family_name":"Meier",
         "birthdate":"1956-01-28",
         "place_of_birth":{  
            "country":"DE",
            "locality":"Musterstadt"
         },
         "nationality":"DE",
         "address":{  
            "locality":"Maxstadt",
            "postal_code":"12344",
            "country":"DE",
            "street_address":"An der Sanddüne 22"
         }
      }
   }
}

The “verified_claims" composite claim contains the actual end-user claims along with the metadata describing trust framework, process and so on. It could also convey evidence, if needed (see https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html#rfc.section.6). This allows to combine verified claims with other claims in the same ID Token or UserInfo response. 

I have to admit I’m not sure whether "https://refeds.org/assurance/profile/cappuccino" or "https://refeds.org/assurance/IAP/medium" would be the appropriate trust framework value.  

I look forward to getting your feedback. 

best regards,
Torsten. 

> On 3. Sep 2019, at 08:31, Marcus Hardt <hardt at kit.edu> wrote:
> 
> On 09/02/19 15:27, Wolfgang Pempe wrote:
>> Am 02.09.19 um 15:14 schrieb Roland Hedberg:
>>> acr and amr definitely goes in the ID Token.
>>> The default for eduperson_assurance would probably be the userinfo endpoint.
>>> But you can always ask for it to be returned in the ID Token.
>> 
>> which would be the most flexible solution. You cannot assume that all
>> identities in an IdM have been subject to the same e.g. identity vetting
>> process because those processes change over time. Insofar at least
>> https://refeds.org/assurance/IAP/* should IMO be released per identity and
>> therefore be returned as part of the ID Token.
> 
> As far as I understand it:
> 
> Yes, it should be released per identity
> 
> Yes, it should be part of the ID token. Then it is in the "amr" claim.
> 
> But, it should also be available in the userinfo. Then as part of the
> eduperson_assurace claim.
> 
> M.
> 
>> Best,
>> Wolfgang
>> 
>>> 
>>>> On 2 Sep 2019, at 15:10, Marcus Hardt <hardt at kit.edu> wrote:
>>>> 
>>>> Hi There,
>>>> 
>>>> thanks for the answers.
>>>> 
>>>> I suppoose that acr and amr go into the ID-Token and eduperson_assurance
>>>> will be available via the userinfo (in some scope), right?
>>>> 
>>>> M.
>>>> 
>>>> On 08/30/19 14:10, Mischa Salle wrote:
>>>>> Hi Marcus,
>>>>> 
>>>>> good that you bring this up!
>>>>> We recently figured out (thanks to Roland for pointing me to it!) that
>>>>> there is both "acr" and "amr", in addition to the REFEDS'
>>>>> eduperson_assurance. Actually I'm not sure why we did not consider amr
>>>>> during the RAF discussions. So perhaps you should produce something like
>>>>> 
>>>>>    "acr" : "https://refeds.org/profile/sfa",
>>>>>    "amr" : [
>>>>>      "https://refeds.org/assurance/ATP/ePA-1d",
>>>>>      "https://refeds.org/assurance/ATP/ePA-1m",
>>>>>      "https://refeds.org/assurance/IAP/local-enterprise",
>>>>>      "https://refeds.org/assurance/IAP/low",
>>>>>      "https://refeds.org/assurance/IAP/medium",
>>>>>      "https://refeds.org/assurance/ID/eppn-unique-no-reassign",
>>>>>      "https://refeds.org/assurance/ID/unique",
>>>>>      "https://refeds.org/assurance/profile/cappuccino"
>>>>>    ],
>>>>>    "eduperson_assurance" : [
>>>>>      "https://refeds.org/assurance/ATP/ePA-1d",
>>>>>      "https://refeds.org/assurance/ATP/ePA-1m",
>>>>>      "https://refeds.org/assurance/IAP/local-enterprise",
>>>>>      "https://refeds.org/assurance/IAP/low",
>>>>>      "https://refeds.org/assurance/IAP/medium",
>>>>>      "https://refeds.org/assurance/ID/eppn-unique-no-reassign",
>>>>>      "https://refeds.org/assurance/ID/unique",
>>>>>      "https://refeds.org/assurance/profile/cappuccino"
>>>>>    ],
>>>>> 
>>>>> which is more or less what Nikhef is now producing.
>>>>> Additionally we also add some information such as the IGTF assurance
>>>>> profile OID (typically https://igtf.net/ap/authn-assurance/birch /
>>>>> urn:oid:1.2.840.113612.5.2.5.2) and authN type, e.g. something like
>>>>>    urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
>>>>> or
>>>>>    urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient
>>>>> (btw you're missing the 'assurance' part of the $PREFIX for cappuccino)
>>>>> 
>>>>> See the OIDC core spec under IDToken, one but last claim,
>>>>> https://openid.net/specs/openid-connect-core-1_0.html#IDToken
>>>>> 
>>>>>    amr
>>>>> 	OPTIONAL. Authentication Methods References. JSON array of
>>>>> 	strings that are identifiers for authentication methods used in
>>>>> 	the authentication. For instance, values might indicate that
>>>>> 	both password and OTP authentication methods were used. The
>>>>> 	definition of particular values to be used in the amr Claim is
>>>>> 	beyond the scope of this specification. Parties using this claim
>>>>> 	will need to agree upon the meanings of the values used, which
>>>>> 	may be context-specific. The amr value is an array of case
>>>>> 	sensitive strings.
>>>>> 
>>>>> For your link [3], the latest version seems to be
>>>>> https://wiki.refeds.org/display/CON/Consultation%3A+SAML2+and+OIDC+Mappings
>>>>> 
>>>>> Cheers,
>>>>> Mischa
>>>>> 
>>>>> On Tue, Aug 27, 2019 at 02:09:48PM +0200, Marcus Hardt wrote:
>>>>>> Hi There,
>>>>>> 
>>>>>> we have a use case for using the Information of the REFEDS Assurance
>>>>>> Framework (RAF)[1] via OIDC.
>>>>>> 
>>>>>> I.e. my home IdP issues me
>>>>>> 
>>>>>> - https://refeds.org/assurance/ATP/ePA-1d
>>>>>> - https://refeds.org/assurance/ATP/ePA-1m
>>>>>> - https://refeds.org/assurance/IAP/local-enterprise
>>>>>> - https://refeds.org/assurance/IAP/low
>>>>>> - https://refeds.org/assurance/IAP/medium
>>>>>> - https://refeds.org/assurance/ID/eppn-unique-no-reassign
>>>>>> - https://refeds.org/assurance/ID/unique
>>>>>> - https://refeds.org/profile/cappuccino
>>>>>> 
>>>>>> Question is how to get these into "OIDC"?
>>>>>> 
>>>>>> Now, there is already some work done in the OIDCRE[2] group, that
>>>>>> resulted in this[3] google doc.
>>>>>> 
>>>>>> [1]https://wiki.refeds.org/display/ASS/REFEDS+Assurance+Framework+ver+1.0
>>>>>> [2]https://wiki.refeds.org/display/GROUPS/OIDCre
>>>>>> [3]https://docs.google.com/document/d/1b-Mlet3Lq7qKLEf1BnHJ4nL1fq-vMe7fzpXyrq2wp08/edit
>>>>>> 
>>>>>> 
>>>>>> Two probelms kept us from putting this information (as a list) into
>>>>>> eduperson_assurance:
>>>>>> 
>>>>>> 1: Singlevaluedness (I'm not sure about this being so, but I was told)
>>>>>> 2: ID Token: Assurance might rather belong into the ID Token (while from
>>>>>>   the research background we tend to put all into the userinfo endpoint.
>>>>>> 
>>>>>> 
>>>>>> Basically, I'm writing to find updated information, or to find a way to
>>>>>> close this item.
>>>>>> 
>>>>>> 
>>>>>> Cheers,
>>>>>> -- 
>>>>>> Marcus.
>>>>> 
>>>>> 
>>>>> 
>>>>>> -- 
>>>>>> openid-specs-rande mailing list
>>>>>> openid-specs-rande at lists.openid.net
>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-rande
>>>>> 
>>>>> 
>>>>> -- 
>>>>> Nikhef                      Room  H155
>>>>> Science Park 105            Tel.  +31-20-592 5102
>>>>> 1098 XG Amsterdam           Fax   +31-20-592 5155
>>>>> The Netherlands             Email msalle at nikhef.nl
>>>>>  __ .. ... _._. .... ._  ... ._ ._.. ._.. .._..
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> Marcus.
>>>> -- 
>>>> openid-specs-rande mailing list
>>>> openid-specs-rande at lists.openid.net <mailto:openid-specs-rande at lists.openid.net>
>>>> http://lists.openid.net/mailman/listinfo/openid-specs-rande <http://lists.openid.net/mailman/listinfo/openid-specs-rande>
>>> - Roland
>>> 
>>> Otium cum dignitate - latin proverb
>>> 
>>> 
>>> 
>> 
>> -- 
>> ---------------------------------------------------------------------
>> Wolfgang Pempe                         Phone  : +49 30 884299-308
>> DFN-Verein                             Fax    : +49 30 884299-370
>> Alexanderplatz 1                       E-Mail : pempe at dfn.de
>> D-10178 Berlin                         WWW    : https://www.dfn.de
>> ---------------------------------------------------------------------
>> --------------------- Deutsches Forschungsnetz ----------------------
>> --------- Germany's National Research and Education Network ---------
>> ---------------------------------------------------------------------
>> 
> 
> 
> 
>> -- 
>> openid-specs-rande mailing list
>> openid-specs-rande at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-rande
> 
> 
> -- 
> Marcus.
> -- 
> openid-specs-rande mailing list
> openid-specs-rande at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-rande

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3923 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-rande/attachments/20190903/7793638a/attachment.p7s>