[Openid-specs-ab] amr vs acr

Nat Sakimura sakimura at gmail.com
Sun Jun 2 23:04:09 UTC 2013


Torsten,

What is your use case for multi valued acr response?

FYI, a client can 'request' multiple acr values.
The server, if it can fulfill, picks one and responds.


2013/6/1 Torsten Lodderstedt <torsten at lodderstedt.net>

> Hi Mike,
>
> can you still remember the arguments? I couldn't find a note about this
> discussion in the respective minutes (
> http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20130304/003231.html
> ).
>
> regards,
> Torsten.
>
> Am 01.06.2013 um 15:25 schrieb Mike Jones <Michael.Jones at microsoft.com>:
>
>  Having a multi-valued “acr” was what the issue originally proposed.
> John, Nat, and I think Tony all argued in the March 4th call that that
> was the wrong thing to do.  They convinced me that they’re right.****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* Torsten Lodderstedt [mailto:torsten at lodderstedt.net<torsten at lodderstedt.net>]
>
> *Sent:* Friday, May 31, 2013 11:26 PM
> *To:* Mike Jones
> *Cc:* John Bradley; OpenId Connect List
> *Subject:* Re: [Openid-specs-ab] amr vs acr****
>
> ** **
>
> Hi,****
>
> ** **
>
> seems no one is really comfortable with the current design. Why not drop
> amr and make acr a multi-value?****
>
> ** **
>
> regards,****
>
> Torsten.****
>
>
> Am 01.06.2013 um 03:55 schrieb Mike Jones <Michael.Jones at microsoft.com>:**
> **
>
>  That aligns with my thinking as well.****
>
>  ****
>
> *From:* John Bradley [mailto:ve7jtb at ve7jtb.com <ve7jtb at ve7jtb.com>]
> *Sent:* Friday, May 31, 2013 6:54 PM
> *To:* Mike Jones
> *Cc:* Nat Sakimura; OpenId Connect List
> *Subject:* Re: [Openid-specs-ab] amr vs acr****
>
>  ****
>
> amr is something people think they want, but it winds up being too
> inflexible    for any real use. Mostly it is token venders that push it.
>  Once an IdP starts saying the user was authenticated wit brand x token or
> card it is too difficult to keep a federation in sync unless it is quite
> small. ****
>
>  ****
>
> act is a good level of abstraction and can cover all the real use cases I
> know of.   ****
>
>  ****
>
> On the other hand amr will let people learn the mistakes of SAML over
> again. ****
>
> It is not the end of the world to have it as an option.  ****
>
>
> Sent from my iPhone****
>
>
> On 2013-05-31, at 10:19 PM, Mike Jones <Michael.Jones at microsoft.com>
> wrote:****
>
>  I disagree with the MUSTs.  We already have language in place saying
> that if claims aren’t understood, they should be ignored, so there’s no
> actual problem.  (Were there a problem, it would apply to “acr” as well.)*
> ***
>
>  ****
>
> I could see going as far as saying, in both “acr” and “amr” that “The
> definition of particular values to be used in the acr/amr Claim is beyond
> the scope of this specification.  Parties using this claim will need to
> agree on the meanings of the values used for it to be useful to them.”****
>
>  ****
>
>                                                                 -- Mike***
> *
>
>  ****
>
> *From:* Nat Sakimura [mailto:sakimura at gmail.com <sakimura at gmail.com>]
> *Sent:* Friday, May 31, 2013 6:06 PM
> *To:* Mike Jones
> *Cc:* Torsten Lodderstedt; OpenId Connect List
> *Subject:* Re: [Openid-specs-ab] amr vs acr****
>
>  ****
>
> Ah, that's the call in the morning of the JICS that you did in the 11th
> floor of NII. ****
>
> I came in late, sitting at a different table that hearing to the call was
> a bit hard but did not mind as I was very much distracted by various things
> to be dealt with JICS. ****
>
>  ****
>
> I remember talking about changing 1,2,3,4 as it became non-compliant to
> the RFC, as well as arguing against conflating authentication method with
> the authentication class, on the basis that authentication method by itself
> is useless and harmful, as in the previous mail. I mistakingly thought that
> I have killed the idea of amr, which apparently was not. ****
>
>  ****
>
> Unfortunately, the discussion is not recorded in
> http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20130304/003231.html.
> ****
>
>  ****
>
> Probably, we should add some warning text to amr then. At the end of the
> definition of arm, how about adding the following? ****
>
>  ****
>
> When using amr, the RP and OP MUST define the common context including the
> meaning, security characteristics, and the compliance requirement for using
> it and the RP MUST be able to evaluate the values according to the defined
> context. ****
>
>  ****
>
> That would mitigate my worries. ****
>
>  ****
>
>  ****
>
>  ****
>
> 2013/6/1 Mike Jones <Michael.Jones at microsoft.com>****
>
> This was one of the two open issues discussed on the 4-Mar-13 working
> group call.  You were on that call, according to the minutes.  We had a
> fairly extensive discussion about the meaning of “acr” and the right way to
> return information about authentication methods used.  Originally the
> request was to allow multi-valued “acr” values.  There was a use case where
> an implementation wanted to communicate the actual methods used such as
> “password”, “OTP”, “code in text message”, etc. and I’d originally
> advocated for letting “acr” be multi-valued, just like PAPE did.  John,
> Tony, and I think you convinced us that that conflating classes with
> methods would create more problems than it would solve and that it was
> better to define an optional claim for returning an array of methods used,
> when needed.****
>
>  ****
>
> On that call we also deleted the LoA values “1”, “2”, “3”, and “4” since
> as part of that discussion, it came up that they are prohibited by RFC
> 6711.  Instead, we replaced the example values used with real values from
> InCommon - urn:mace:incommon:iap:bronze and urn:mace:incommon:iap:silver.*
> ***
>
>  ****
>
> I don’t think that we should require “acr” when “amr” is used, because
> there may not be a class, even though there are methods.  It depends upon
> the business context in which the parties are communicating.  Like “acr”,
> “amr” is only useful when the values are understood by both parties.
> Nonetheless, it’s better to have a standard claim for these methods than to
> have everyone make up a different one.  This kind of information is used in
> practice, in some contexts.****
>
>  ****
>
>                                                                 -- Mike***
> *
>
>  ****
>
> *From:* openid-specs-ab-bounces at lists.openid.net [mailto:
> openid-specs-ab-bounces at lists.openid.net] *On Behalf Of *Nat Sakimura
> *Sent:* Friday, May 31, 2013 4:53 PM
> *To:* Torsten Lodderstedt
> *Cc:* OpenId Connect List
> *Subject:* Re: [Openid-specs-ab] amr vs acr****
>
>  ****
>
> s/ where acr gives more context to the values of acr. / where acr gives
> more context to the values of amr. /****
>
>  ****
>
> 2013/6/1 Nat Sakimura <sakimura at gmail.com>****
>
> I suppose you mean amr, not acm. ****
>
>  ****
>
> I actually was not aware of amr till now. It seems it was a fairly quick
> decision made between March 4 and 6. ****
>
> See
> https://bitbucket.org/openid/connect/issue/789/make-acr-claim-values-be-arrays-of-acr
> ****
>
> At the time, I was so busy managing JICS 2013, so it went unnoticed for
> me. ****
>
> I also searched through the list archive, but I cannot find the topic in
> it. There is no record of the decision on the call notes either. ****
>
>  ****
>
> Mike, could you point us to the record how the WG decision was reached? **
> **
>
>  ****
>
> Apparently, amr is the list of authentication methods, while acr is the
> indicator of the identity proofing and authentication quality. ****
>
> i.e., amr is just the list of such things like "password", "otp", etc.
> while acr is "InCommons Silver", "ISO29115 LoA 3", etc. ****
>
>  ****
>
> Personally, I do not see much value in amr since it does not indicate any
> quality information. It may even be harmful when used without context in
> the sense that it may create sense of false security to the relying
> parties. For example, "otp" by itself does not mean it is secure. An OTP
> system with badly managed seed will generate a predictable sequence of "one
> time passwords", which is not secure at all. It would only be meaningful
> when there is an assurance that the system is properly managed. In this
> respect, amr may be meaningful as an auxiliary information only when it is
> used with acr, where acr gives more context to the values of acr. ****
>
>  ****
>
> I might want to require acr if amr is used, or drop amr, but that is only
> my personal opinion. ****
>
>  ****
>
> 2013/6/1 Torsten Lodderstedt <torsten at lodderstedt.net>****
>
> Hi,
>
> could someone please describe me the difference between the id token
> members acr and acm? From my understanding, they are just the same. I'm
> also interested to learn why the authorization request allows to specify
> multiple acrs but does not support to specify any authentication method
> (via acm). Additionally, why is there no way to indicate more than one acr
> in the id token?
>
> Thanks in advance,
> Torsten.
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab****
>
>
>
> ****
>
>  ****
>
> --
> Nat Sakimura (=nat)****
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en****
>
>
>
> ****
>
>  ****
>
> --
> Nat Sakimura (=nat)****
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en****
>
>
>
> ****
>
>  ****
>
> --
> Nat Sakimura (=nat)****
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en****
>
>  _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab****
>
>   _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab****
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130603/6e6d9f93/attachment-0001.html>


More information about the Openid-specs-ab mailing list