I am in favor of William's proposal. In addition, I would like to see one for 2nd channel auth, 2ch. That would indicate some resilience against MITB.
On Saturday, July 25, 2015, Brian Campbell <bcampb...@pingidentity.com> wrote: > There's a method of authentication that is gaining in popularity which I'd > propose adding a method for. It is typically used as a second factor where > after a primary auth, like username and password, a push notification is > sent to the user's phone and they acknowledge it from the device. We have > the PingID product <https://www.pingidentity.com/en/products/pingid.html> > that does it and Entrust > <http://www.entrust.com/resource/entrust-identityguard-mobile-push-authentication-for-vpn-and-web-access> > and Duo <https://www.duosecurity.com/product/methods/duo-mobile>, among > others I'm sure, offer something similar. > > It's commonly called "mobile push authentication" so maybe "mpa" could be > the amr value. But, as Nat pointed out, the really interesting > characteristic is that it's a second factor that utilizes only a secondary > channel - so perhaps "sca" for "second channel authentication" would be a > more appropriate general amr name. > > Thoughts are welcome. But I believe it's becoming prevalent enough that it > deserves its own amr value in this doc. > > > > > On Thu, Jul 23, 2015 at 6:29 PM, Mike Jones <michael.jo...@microsoft.com > <javascript:_e(%7B%7D,'cvml','michael.jo...@microsoft.com');>> wrote: > >> I agree that an obvious good thing to do is to add spec references to >> the field definitions. >> >> >> >> I need to investigate use cases for amr_values. I think this came from >> developers who actually wanted this for a particular purpose but I’ll have >> to get back to the WG on that. It’s defined here, rather than in another >> spec, because it’s highly related to the “amr” values. >> >> >> >> -- Mike >> >> >> >> *From:* OAuth [mailto:oauth-boun...@ietf.org >> <javascript:_e(%7B%7D,'cvml','oauth-boun...@ietf.org');>] *On Behalf Of *Nat >> Sakimura >> *Sent:* Thursday, July 23, 2015 6:22 PM >> *To:* William Denniss >> *Cc:* <oauth@ietf.org <javascript:_e(%7B%7D,'cvml','oauth@ietf.org');>> >> *Subject:* Re: [OAUTH-WG] Authentication Method Reference Values >> Specification >> >> >> >> 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 <wdenn...@google.com >> <javascript:_e(%7B%7D,'cvml','wdenn...@google.com');>>: >> >> 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 < >> bcampb...@pingidentity.com >> <javascript:_e(%7B%7D,'cvml','bcampb...@pingidentity.com');>> 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 <michael.jo...@microsoft.com >> <javascript:_e(%7B%7D,'cvml','michael.jo...@microsoft.com');>> 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 >> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fself-issued.info%2fdocs%2fdraft-jones-oauth-amr-values-00.html%23acrRelationship&data=01%7c01%7cMichael.Jones%40microsoft.com%7c45f73eec59c2463664de08d2937adf52%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6%2blPSyG0xfBMg0jxKaQt1lAcW6GV3%2fje4dmkE%2bb7Q8o%3d> >> is a start at that. >> >> >> >> -- Mike >> >> >> >> *From:* John Bradley [mailto:ve7...@ve7jtb.com >> <javascript:_e(%7B%7D,'cvml','ve7...@ve7jtb.com');>] >> *Sent:* Thursday, July 23, 2015 9:30 AM >> *To:* Justin Richer >> *Cc:* Mike Jones; <oauth@ietf.org >> <javascript:_e(%7B%7D,'cvml','oauth@ietf.org');>> >> *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 <jric...@mit.edu >> <javascript:_e(%7B%7D,'cvml','jric...@mit.edu');>> 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 <michael.jo...@microsoft.com >> <javascript:_e(%7B%7D,'cvml','michael.jo...@microsoft.com');>> 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 >> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-jones-oauth-amr-values-00&data=01%7c01%7cMichael.Jones%40microsoft.com%7c45f73eec59c2463664de08d2937adf52%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=mJ47K%2bCepKxx8Zyst%2bAveZIZb6EyTRYv6Lv2wp6z9vY%3d> >> >> >> >> An HTML formatted version is also available at: >> >> · >> http://self-issued.info/docs/draft-jones-oauth-amr-values-00.html >> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fself-issued.info%2fdocs%2fdraft-jones-oauth-amr-values-00.html&data=01%7c01%7cMichael.Jones%40microsoft.com%7c45f73eec59c2463664de08d2937adf52%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=T9VLqO%2bJjpfBiF76qBEqkKO1btDrPra59sq%2bhNUpN5I%3d> >> >> >> >> -- Mike >> >> >> >> P.S. This note was also posted at http://self-issued.info/?p=1429 >> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fself-issued.info%2f%3fp%3d1429&data=01%7c01%7cMichael.Jones%40microsoft.com%7c45f73eec59c2463664de08d2937adf52%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=zv2zIrlN0UGAFKe9rADVphUGnJKOgHwiRYXk0toa5QQ%3d> >> and >> as @selfissued >> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftwitter.com%2fselfissued&data=01%7c01%7cMichael.Jones%40microsoft.com%7c45f73eec59c2463664de08d2937adf52%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=GZB6%2f0FYZPSX0RUxQkjMUAc5uGaTJVuZbkYUcuSFBkA%3d> >> . >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <javascript:_e(%7B%7D,'cvml','OAuth@ietf.org');> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7cMichael.Jones%40microsoft.com%7c45f73eec59c2463664de08d2937adf52%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=4aNhTxGD%2f9w8qD9WPXpi2%2bQfiprJDbsF2PK5EBxau34%3d> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <javascript:_e(%7B%7D,'cvml','OAuth@ietf.org');> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7cMichael.Jones%40microsoft.com%7c45f73eec59c2463664de08d2937adf52%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=4aNhTxGD%2f9w8qD9WPXpi2%2bQfiprJDbsF2PK5EBxau34%3d> >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <javascript:_e(%7B%7D,'cvml','OAuth@ietf.org');> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7cMichael.Jones%40microsoft.com%7c45f73eec59c2463664de08d2937adf52%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=4aNhTxGD%2f9w8qD9WPXpi2%2bQfiprJDbsF2PK5EBxau34%3d> >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <javascript:_e(%7B%7D,'cvml','OAuth@ietf.org');> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7cMichael.Jones%40microsoft.com%7c45f73eec59c2463664de08d2937adf52%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=4aNhTxGD%2f9w8qD9WPXpi2%2bQfiprJDbsF2PK5EBxau34%3d> >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <javascript:_e(%7B%7D,'cvml','OAuth@ietf.org');> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7cMichael.Jones%40microsoft.com%7c45f73eec59c2463664de08d2937adf52%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=4aNhTxGD%2f9w8qD9WPXpi2%2bQfiprJDbsF2PK5EBxau34%3d> >> >> >> >> >> >> -- >> >> Nat Sakimura (=nat) >> >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fnat.sakimura.org%2f&data=01%7c01%7cMichael.Jones%40microsoft.com%7c45f73eec59c2463664de08d2937adf52%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=OIEfHEFdwYJMfEWkZeAYxrEdedcUrtVuZaYw86jCBks%3d> >> @_nat_en >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <javascript:_e(%7B%7D,'cvml','OAuth@ietf.org');> >> https://www.ietf.org/mailman/listinfo/oauth >> >> > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
