[openid-specs-rande] RAF expression in OIDC
Nicolas Liampotis
nliam at grnet.gr
Thu Sep 5 13:49:33 UTC 2019
Hi all,
> On 5 Sep 2019, at 16:39, Mischa Salle <msalle at nikhef.nl> wrote:
>
> Hi all,
>
> On Tue, Sep 03, 2019 at 08:31:12AM +0200, Marcus Hardt 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.
>
> I think you and Wolfgang are now a bit confused. Both ID token and
> userinfo are released per identity. The difference is that there is a
> preference to release in the ID token the information relating to the
> actual authentication that took place, while the userinfo typically
> releases the profile information of the user. There is no hard guideline
> stating this though. Personally I think that it probably makes most
> sense to release both amr and eduperson_assurace in the ID token, I
> don't think it's really profile information, but they could also both be
> released from the userinfo in certain cases I guess.
I think that it makes sense to release acr/amr and eduperson_assurance through *both* the ID token and the UserInfo endpoint. Furthermore, given that assurance information can be used for authorisation purposes it would also be a good idea to expose these claims through the introspection endpoint [https://tools.ietf.org/html/rfc7662].
Cheers,
Nicolas
> See also Nicolas' email from Fri, 30 Aug 2019 12:47:11 +0000 about what
> to put in amr vs. eduperson_assurance.
>
> Cheers,
> Mischa
>
>>>>> 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
>
>
> --
> 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
> __ .. ... _._. .... ._ ... ._ ._.. ._.. .._..
> --
> openid-specs-rande mailing list
> openid-specs-rande at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-rande
--
Nicolas Liampotis
AAI Research Engineer
GRNET - Greek Research and Technology Network
7, Kifisias Av., 115 23, Athens, Greece
k: 0xAC118B82
t: +30 210 7474264
f: +30 210 7474490
Follow us: www.grnet.gr
Twitter: @grnet_gr | Facebook: @grnet.gr
LinkedIn: grnet | YouTube: GRNET EDET
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-rande/attachments/20190905/ecc7a9ab/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.openid.net/pipermail/openid-specs-rande/attachments/20190905/ecc7a9ab/attachment-0001.asc>
More information about the openid-specs-rande
mailing list