So, allow me a naive question. I supppose there are good random otp, as well as pretty bad otp etc. Would it be useful to say just "otp". Would it not be better to have at least a field that references a spec that specifies the security requirement for that mechanism?
2015-07-23 12:05 GMT+02:00 William Denniss <[email protected]>: > Thanks for drafting this Mike. I'm in favor of having this registry. > > In addition to the specific values, I propose we add some generic ones too > (trying to follow your naming scheme): > > "rba": "risk-based auth" > "upt": "user presence test" > > My fear of making things too specific is that RPs may get lost in the > weeds trying to work out what things they should care about and how. As an > IdP we like to guide RPs through these kinds of decisions, and prefer to > pass a more high level indication of what happened (such as these two > values). If someone wanted to have best of both worlds, then both could be > asserted, e.g. "upt fpt" to indicate that the user presence was tested, > using a fingerprint test. > > Regarding the proposed "wia" value. I don't know what it is, and the spec > doesn't help me find out, can a reference be added? I also wonder if it > could be genericized to avoid being vendor specific values – but mostly I > just want to understand what it is. Almost all the other values are > self-explanatory, perhaps "pop" could use a reference as well (or maybe > just a longer explanation). > > I don't see the immediate value of "amr_values", can you elaborate with > some places where this would be applied? Separately, I wonder if an > extension to OIDC should be included in this doc, which is otherwise a > fairly clean registry spec that could be used more broadly. > > On Thu, Jul 23, 2015 at 10:49 AM, Brian Campbell < > [email protected]> wrote: > >> So maybe a naive question but why does this draft define "amr_values" >> while also suggesting that it's fragile and that "acr" & "acr_values" is >> preferable? Seems contradictory. And I doubt I'm the only one that will >> find it confusing. >> >> On Thu, Jul 23, 2015 at 9:35 AM, Mike Jones <[email protected]> >> wrote: >> >>> The key part of this is establishing a registry. That can only be >>> done in an RFC. >>> >>> >>> >>> John, I encourage you to submit text beefing up the arguments about why >>> using “acr” is preferable. The text at >>> http://self-issued.info/docs/draft-jones-oauth-amr-values-00.html#acrRelationship >>> is a start at that. >>> >>> >>> >>> -- Mike >>> >>> >>> >>> *From:* John Bradley [mailto:[email protected]] >>> *Sent:* Thursday, July 23, 2015 9:30 AM >>> *To:* Justin Richer >>> *Cc:* Mike Jones; <[email protected]> >>> *Subject:* Re: [OAUTH-WG] Authentication Method Reference Values >>> Specification >>> >>> >>> >>> I don’t personally have a problem with people defining values for AMR >>> and creating a IANA registry. >>> >>> >>> >>> That exists for ACR. >>> >>> >>> >>> I am on record as not supporting clients requesting amr as it ai a bad >>> idea and the spec mentions that at the same time it defines a new request >>> parameter for it. >>> >>> >>> >>> It is probably not something I will put any real effort into fighting, >>> if people insist on it. I will continue to recommend only using ACR in the >>> request. >>> >>> >>> >>> John B. >>> >>> >>> >>> On Jul 23, 2015, at 9:21 AM, Justin Richer <[email protected]> wrote: >>> >>> >>> >>> Useful work, but shouldn’t this be defined in the OIDF, where the “amr" >>> parameter is defined? >>> >>> >>> >>> — Justin >>> >>> >>> >>> On Jul 22, 2015, at 7:48 PM, Mike Jones <[email protected]> >>> wrote: >>> >>> >>> >>> Phil Hunt and I have posted a new draft that defines some values used >>> with the “amr” (Authentication Methods References) claim and >>> establishes a registry for Authentication Method Reference values. These >>> values include commonly used authentication methods like “pwd” >>> (password) and “otp” (one time password). It also defines a parameter >>> for requesting that specific authentication methods be used in the >>> authentication. >>> >>> >>> >>> The specification is available at: >>> >>> · https://tools.ietf.org/html/draft-jones-oauth-amr-values-00 >>> >>> >>> >>> An HTML formatted version is also available at: >>> >>> · >>> http://self-issued.info/docs/draft-jones-oauth-amr-values-00.html >>> >>> >>> >>> -- Mike >>> >>> >>> >>> P.S. This note was also posted at http://self-issued.info/?p=1429 and >>> as @selfissued <https://twitter.com/selfissued>. >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
