[Openid-specs-mobile-profile] ACR values

John Bradley jbradley at mac.com
Tue Nov 24 20:00:58 UTC 2015


I don’t see anything in moderation for you. 

I haven’t had any trouble posting to the list that I know of.

There are two ways to request a acr and they are slightly different.

The first as you point out is using the acr_valuses claim.
This is considered voluntary by the IdP, the Idp must try and match them in order of preference,  but if it dosen’t it can return another acr value.
eg if you ask for single factor but the IdP only has pin lock confirmation eg soft 2 factor then the IdP could reply with soft 2 factor.

The other is to use the acr claim in the request token.
http://openid.net/specs/openid-connect-core-1_0.html#acrSemantics <http://openid.net/specs/openid-connect-core-1_0.html#acrSemantics>

eg
  "acr": {"essential": true,
          "values": ["urn:mace:incommon:iap:silver",
                     "urn:mace:incommon:iap:bronze"]}

This allows the Client to specify an exact match.  If the IdP cant supply one of the acr values by getting the user to step up then it must return a failed authentication attempt.

I think expanding on this is the more important thing for the core profile.

Without essential the IdP might opt to return the lowest one in the list if the user is already at that level.  

I suspect that we want MODRNA IdP to try and step up to the highest level asked for if it is possible. 
I guess the open question is what should the IdP return if that fails.   

They could conceivably leave the user at the lower level and return that. 

Do we want to have an additional MODRNA constraint on the IdP that if they try to step the user up because the device supports that method, and it fails then they need to return an error.

This is the sort of thing that would normally be part of the trust framework of the LoA values, but is probably useful to mail down here.

John B.



> On Nov 24, 2015, at 1:14 PM, philippe.clement at orange.com wrote:
> 
> Dear all, seems like I have concerns with the mail delivery system addressing the mail list "openid-specs-mobile-profile at lists.openid.net <mailto:openid-specs-mobile-profile at lists.openid.net>", have you the same problem or does this concern my company ?
> Philippe
> ______________________________________________
> 
> Échec de la remise pour ces destinataires ou groupes :
> openid-specs-mobile-profile at lists.openid.net <mailto:openid-specs-mobile-profile at lists.openid.net>
> Votre message n'a pas été remis, car le fournisseur de messagerie du destinataire l'a rejeté.
> L'organisation suivante a refusé votre message : smtp1.osuosl.org <http://smtp1.osuosl.org/>.
> _____________________________________________
> 
> -----Message d'origine-----
> De : CLEMENT Philippe IMT TECHNO 
> Envoyé : mardi 24 novembre 2015 17:07
> À : Lodderstedt, Torsten
> Cc : Mike Jones; openid-specs-mobile-profile at lists.openid.net <mailto:openid-specs-mobile-profile at lists.openid.net>
> Objet : RE: [Openid-specs-mobile-profile] ACR values
> 
> Hi Torsten,
> 
> The text you mention refers to the acr parameter in the ID Token, once the authentication is done.
> 
> I'm refereeing on this text:
> 
> 3.  Authentication
> 3.1.2.1.  Authentication Request
> This specification also defines the following request parameters: 
>  acr_values
>  OPTIONAL. Requested Authentication Context Class Reference values. Space-separated string that specifies the acr values that the Authorization Server is being requested to use for processing this Authentication Request, with the values appearing in order of preference. The Authentication Context Class satisfied by the authentication performed is returned as the acr Claim Value, as specified in Section 2 (ID Token). The acr Claim is requested as a Voluntary Claim by this parameter.
> 
> Kind regards,
> Philippe
> 
> -----Message d'origine-----
> De : Lodderstedt, Torsten [mailto:t.lodderstedt at telekom.de <mailto:t.lodderstedt at telekom.de>] Envoyé : mardi 24 novembre 2015 16:00 À : CLEMENT Philippe IMT TECHNO Cc : Mike Jones; openid-specs-mobile-profile at lists.openid.net <mailto:openid-specs-mobile-profile at lists.openid.net>
> Objet : AW: [Openid-specs-mobile-profile] ACR values
> 
> Hi Philippe,
> 
> are you refering to this text?
> 
> acr
> OPTIONAL. Authentication Context Class Reference. String specifying an Authentication Context Class Reference value that identifies the Authentication Context Class that the authentication performed satisfied. The value "0" indicates the End-User authentication did not meet the requirements of ISO/IEC 29115 [ISO29115] level 1. Authentication using a long-lived browser cookie, for instance, is one example where the use of "level 0" is appropriate. Authentications with level 0 SHOULD NOT be used to authorize access to any resource of any monetary value. (This corresponds to the OpenID 2.0 PAPE [OpenID.PAPE] nist_auth_level 0.) An absolute URI or an RFC 6711 [RFC6711] registered name SHOULD be used as the acr value; registered names MUST NOT be used with a different meaning than that which is registered. Parties using this claim will need to agree upon the meanings of the values used, which may be context-specific. The acr value is a case sensitive string.
> 
> Best regards,
> Torsten.
> 
> -----Ursprüngliche Nachricht-----
> Von: philippe.clement at orange.com [mailto:philippe.clement at orange.com]
> Gesendet: Dienstag, 24. November 2015 15:45
> An: Lodderstedt, Torsten
> Cc: Mike Jones; openid-specs-mobile-profile at lists.openid.net
> Betreff: RE: [Openid-specs-mobile-profile] ACR values
> 
> Hi Torsten,
> 
> To be less elliptic, I'm just trying to find some simplistic way to get out of this discussion. In a nutshell, trying to see if we can get rid off speaking levels of assurance in our workgroup and Modrna auth doc. 
> From my point of view, what is mentioned in the OIDC core spec should be enough for the mobile profile. 
> 
> Kind regards,
> Philippe
> 
> -----Message d'origine-----
> De : Lodderstedt, Torsten [mailto:t.lodderstedt at telekom.de] Envoyé : mardi 24 novembre 2015 14:04 À : CLEMENT Philippe IMT TECHNO Cc : Mike Jones; openid-specs-mobile-profile at lists.openid.net
> Objet : AW: [Openid-specs-mobile-profile] ACR values
> 
> Hi Philippe,
> 
> what does it mean with respect to the topic at hand? As I said (at least I tried :-)), my focus is on getting something reasonable/suitable done.
> 
> best regards,
> Torsten.
> 
> -----Ursprüngliche Nachricht-----
> Von: philippe.clement at orange.com [mailto:philippe.clement at orange.com]
> Gesendet: Dienstag, 24. November 2015 13:13
> An: openid-specs-mobile-profile at lists.openid.net; Mike Jones; Lodderstedt, Torsten
> Betreff: RE: [Openid-specs-mobile-profile] ACR values
> 
> sent again due to mail failure...
> 
> -----Message d'origine-----
> De : CLEMENT Philippe IMT TECHNO
> Envoyé : mardi 24 novembre 2015 10:40
> À : Lodderstedt, Torsten; Mike Jones; openid-specs-mobile-profile at lists.openid.net
> Objet : RE: [Openid-specs-mobile-profile] ACR values
> 
> Dear all,
> I went back to the charter to check the purpose of the workgroup:
> __________________
> 
> 2) Purpose:
> Developing a profile of OpenID Connect intended to be appropriate for use by mobile network operators (MNOs) providing identity services to RPs and for RPs in consuming those services as well as any other party wishing to be interoperable with this profile.
> __________________
> 
> I think that means that we work for a OIDC profile of OIDC adapted for MNOs, not exclusively for Mobile Connect that is one of different potential services MNO offer to partners. 
> 
> Hope this helps
> Philippe
> 
> -----Message d'origine-----
> De : Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] De la part de Lodderstedt, Torsten Envoyé : lundi 23 novembre 2015 18:28 À : Mike Jones; openid-specs-mobile-profile at lists.openid.net
> Objet : Re: [Openid-specs-mobile-profile] ACR values
> 
> Hi Mike,
> 
> thanks for your proposal. I think we can drop the "credential" part. It makes sense if we try to used ISO levels in order to indicate we cover credential/authentication levels only, not identity validation.
> 
> I'm rather reluctant to start with generic OpenId ACR value names. I prefer to start with the definition of what is really needed for MODRNA/Mobile Connect. Reaching consensus in the group will be difficult enough. 
> 
> I would rather suggest to have a discussions on generic ACR values later on with HEART, iGov and the new FIDO WG.
> 
> best regards,
> Torsten. 
> 
> -----Ursprüngliche Nachricht-----
> Von: Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] Im Auftrag von Mike Jones
> Gesendet: Sonntag, 22. November 2015 20:50
> An: Torsten Lodderstedt; openid-specs-mobile-profile at lists.openid.net
> Betreff: Re: [Openid-specs-mobile-profile] ACR values
> 
> I'd suggest these names instead:
> - urn:openid:acr:credential:password_less (meaning: possession or inherence is ok)
> - urn:openid:acr:credential:2factor (any two factors, software-based solutions are ok)
> - urn:openid:acr:credential:2factor_tamper_resistant (any two factors, hardware token required)
> 
> I think that the names should not be MODRNA-specific.  And URNs are normally spelled with all lowercase characters.  Like OpenID Connect claim names, when there are multiple words in a name, separate them with underscores.
> 
> Also, is there a reason to have the "credential:" part in the URNs?  I'd suggest dropping that part as well, for brevity.  The size of the ID Token still matters (especially in mobile!).
> 
> 				-- Mike
> 
> -----Original Message-----
> From: Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] On Behalf Of Torsten Lodderstedt
> Sent: Sunday, November 22, 2015 11:42 AM
> To: openid-specs-mobile-profile at lists.openid.net
> Subject: [Openid-specs-mobile-profile] ACR values
> 
> Hi all,
> 
> based on the discussions in the last WG call, I think we are running circles again when it comes to ACR values.
> 
> What I got:
> - usage of LOA values from ISO 29115 seems to confuse people (because they seem to be not as specfic as we thought and cover identification as
> well)
> - new EU regulations use other terms and the number of authentication levels differ
> 
> What do you think about the following proposal:
> 
> In the end, we want to give the RP a way to request authentication levels, which are specific to Mobile Connect/MODRNA. Why don't we define ACR value names, which exactly correspond to what we intend to use? From my perspective, Mobile Connect requires the following levels:
> - urn:openid:modrna:acr:credential:PasswordLess (meaning: posession or inherence is ok)
> - urn:openid:modrna:acr:credential:TwoFactor (any two factors, software-based solutions are ok)
> - urn:openid:modrna:acr:credential:TwoFactorTamperResistant (any two factors, hardware token required)
> 
> Those values are intentionally MODRNA specific and could be mapped (if
> needed) to any other model.
> 
> What do you think?
> 
> best regards,
> Torsten.
> _______________________________________________
> Openid-specs-mobile-profile mailing list Openid-specs-mobile-profile at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
> _______________________________________________
> Openid-specs-mobile-profile mailing list Openid-specs-mobile-profile at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
> _______________________________________________
> Openid-specs-mobile-profile mailing list Openid-specs-mobile-profile at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> 
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> 
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorization.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or falsified.
> Thank you.
> 
> <Mail Attachment.eml>

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


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