[Openid-specs-ab] amr vs acr

Tim Bray tbray at textuality.com
Sat Jun 1 06:47:17 UTC 2013


Realistically, it has to be claim names.  In some cases, spec-defined names
have spec-constrained values and it's not OK to ignore insane values of
email_verified or some such.   -T


On Fri, May 31, 2013 at 11:37 PM, Nat Sakimura <sakimura at gmail.com> wrote:

> Actually, Messages say re: JWT, "Any Claims used that are not understood
> MUST be ignored."
> Now, the question is, by this statement, it is talking about the (1) claim
> names or (2) claim values, or (3) both.
> We may want to tighten it up as well.
>
> Also, when we speak of "understand", it again is a bit vague. The text I
> added was an attempt to write "understand" in this context in a more
> precise way.
>
>
>
> 2013/6/1 Mike Jones <Michael.Jones at microsoft.com>
>
>>  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]
>> *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****
>>
>
>
>
> --
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130531/b532cb46/attachment-0001.html>


More information about the Openid-specs-ab mailing list