+1 Phil
> On Feb 15, 2016, at 16:50, John Bradley <ve7...@ve7jtb.com> wrote: > > The question is what counts as re-authentication. > > It may be that the environment is changing. Re-prompting for a password in > many cased just tells you the user has a form filler. > > It may be better to use risk based factors such as prompting for a pin, or > using a local passive biometric, eg has the phone got screen lock and is it > in proximity to the persons smart watch etc. > > What google seems to be doing is using the amr to say how they did the last > authentication and leave it up to the client to decide if it is good enough. > > Simple always ask for a password may no longer provide the security that most > people think it is giving. > > Looking at what enterprise customers are asking for, they are becoming more > concerned with checking the MDM posture of the device at authentication. > > This is a larger conversation about authentication context and methods. > > The establishment of the amr registry will provide a place to document a part > of this, however authentication context (there is already a registry) and amr > values themselves are probably out of scope for this WG. > > John B. > > >> On Feb 15, 2016, at 8:22 PM, Jim Manico <j...@manicode.com> wrote: >> >> Polite comment, Google in general is pretty "open" about session management >> in general - long idle timeout and no apparent absolute timeout. For a bank >> or other organization that produces high risk software, this is not standard >> practice. Re-authentication is a critical security boundary, not prompting >> the user for re-authentication credentials is unacceptable in those >> environments. >> >> I may be jumping in out of context, but fair? >> >> -- >> Jim Manico >> @Manicode >> +1 (808) 652-3805 >> >>> On Feb 15, 2016, at 3:36 PM, William Denniss <wdenn...@google.com> wrote: >>> >>> We return 'amr' claims in ID Tokens if "max_age" is requested (per OpenID >>> Connect), e.g.: >>> >>> https://accounts.google.com/o/oauth2/auth?redirect_uri=https%3A%2F%2Fdevelopers.google.com%2Foauthplayground&response_type=code&client_id=407408718192.apps.googleusercontent.com&scope=openid+profile&approval_prompt=force&access_type=offline&max_age=1 >>> >>> The reason we do this is to be explicit about how we are processing the >>> "max_age" reauth request, specifically that we don't always prompt the user >>> to reauthenticate directly (but do perform in-session risk analysis). >>> >>> I can see us potentially using the more generic amr values like "user", and >>> "mfa" but we will probably avoid very specific ones like "sms" or "otp" to >>> avoid brittle relationships with RPs. That said, I don't object to those >>> being in the registry, perhaps there is value in some tightly coupled >>> enterprise configurations. >>> >>> >>>> On Sun, Feb 14, 2016 at 5:30 AM, Torsten Lodderstedt >>>> <tors...@lodderstedt.net> wrote: >>>> Hi Denniss, >>>> >>>> out of curiosity: Does Google use amr values? >>>> >>>> best regards, >>>> Torsten. >>>> >>>> >>>>> Am 14.02.2016 um 02:40 schrieb William Denniss: >>>>> >>>>> >>>>>> On Sat, Feb 13, 2016 at 12:19 PM, Mike Jones >>>>>> <michael.jo...@microsoft.com> wrote: >>>>>> It's an acceptable fallback option if the working group decides it >>>>>> doesn't want to register the values that are already in production use >>>>>> at the time we establish the registry. But add William points out, >>>>>> Google is already using some of these values. Microsoft is using some of >>>>>> them. The OpenID MODRNA specs are using some of them. So it seems more >>>>>> efficient to register them at the same time. >>>>>> >>>>>> That would be my preference. >>>>> >>>>> +1, it is also my preference to register the current values. >>>>> >>>>> I don't see any harm in the spec that establishes the registry also >>>>> seeding it with all known values in use at the time of drafting, >>>>> regardless of the group that originally specified them. Makes the >>>>> original spec more useful, and avoids the need to submit each value for >>>>> consideration separately – they can be all be reviewed at the same time. >>>>> >>>>> >>>>>> From: Justin Richer >>>>>> Sent: 2/13/2016 11:11 AM >>>>>> To: Phil Hunt >>>>>> >>>>>> Cc: <oauth@ietf.org> >>>>>> Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for >>>>>> Adoption Finalized >>>>>> >>>>>> Can we just do that, then? Seems to be the easiest way to address >>>>>> various needs and concerns. >>>>>> >>>>>> — Justin >>>>>> >>>>>>> On Feb 13, 2016, at 11:08 AM, Phil Hunt (IDM) <phil.h...@oracle.com> >>>>>>> wrote: >>>>>>> >>>>>>> Yes >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> On Feb 13, 2016, at 07:59, "tors...@lodderstedt.net" >>>>>>> <tors...@lodderstedt.net> wrote: >>>>>>> >>>>>>>> So basically, the RFC could also just establish the new registry and >>>>>>>> oidf could feel in the values? >>>>>>>> >>>>>>>> (just trying to understand) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -------- Originalnachricht -------- >>>>>>>> Betreff: RE: [OAUTH-WG] Authentication Method Reference Values: Call >>>>>>>> for Adoption Finalized >>>>>>>> Von: Mike Jones <michael.jo...@microsoft.com> >>>>>>>> An: tors...@lodderstedt.net,John Bradley <ve7...@ve7jtb.com> >>>>>>>> Cc: oauth@ietf.org >>>>>>>> >>>>>>>> The context that most people on this thread probably don’t have is >>>>>>>> that an IANA registry can only be established by an RFC. Non-RFC >>>>>>>> specifications, such as OpenID specifications, can *register* values >>>>>>>> in a registry, but they cannot *establish* a registry. The OpenID >>>>>>>> Foundation inquired about this with the IETF before OpenID Connect was >>>>>>>> finalized and learned that its specifications could not establish IANA >>>>>>>> registries. Otherwise, they would have. >>>>>>>> >>>>>>>> >>>>>>>> Instead, RFCs need to be created to establish registries – even for >>>>>>>> values first defined in non-RFC specifications. This specification is >>>>>>>> one example of doing this. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- Mike >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of >>>>>>>> tors...@lodderstedt.net >>>>>>>> Sent: Saturday, February 13, 2016 6:37 AM >>>>>>>> To: John Bradley <ve7...@ve7jtb.com> >>>>>>>> Cc: oauth@ietf.org >>>>>>>> Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call >>>>>>>> for Adoption Finalized >>>>>>>> >>>>>>>> >>>>>>>> We clearly have this problem between oauth and oidc. Just take a look >>>>>>>> at the discovery thread. >>>>>>>> >>>>>>>> According to you argument I see two options: >>>>>>>> (1) amr stays an oidc claim, is used in oidc only and the oauth wg >>>>>>>> just publishes the registry entries. In this case, the spec should >>>>>>>> clearly explain this. >>>>>>>> (2) amr is of any use in oauth (although it has been invented in oidc) >>>>>>>> - than define it and motivate it's use in oauth in this spec. >>>>>>>> >>>>>>>> Right now, I think it creates the impression oauth is for >>>>>>>> authentication. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -------- Originalnachricht -------- >>>>>>>> Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call >>>>>>>> for Adoption Finalized >>>>>>>> Von: John Bradley <ve7...@ve7jtb.com> >>>>>>>> An: tors...@lodderstedt.net >>>>>>>> Cc: roland.hedb...@umu.se,oauth@ietf.org >>>>>>>> >>>>>>>> This is not a issue between oauth and OIDC. >>>>>>>> >>>>>>>> >>>>>>>> This has to do with the registry for JWT being in OAuth. Many >>>>>>>> protocols that use JWT are going to want to register claims. >>>>>>>> >>>>>>>> We can’t ask them to all move the parts of there specs that use JWT to >>>>>>>> OAuth. >>>>>>>> >>>>>>>> >>>>>>>> Perhaps JWT should have been part of JOSE, but that is water under the >>>>>>>> bridge. >>>>>>>> >>>>>>>> >>>>>>>> The OAuth WG is responsible for JWT and it’s registry, and we will >>>>>>>> need to deal with registering claims. >>>>>>>> >>>>>>>> >>>>>>>> I guess that we can tell people that they need to publish the specs >>>>>>>> defining the claims someplace else, and just do the registry part. >>>>>>>> >>>>>>>> However doing that will probably not improve interoperability and >>>>>>>> understanding. >>>>>>>> >>>>>>>> >>>>>>>> This document defines the claim for JWT in general. We still have >>>>>>>> almost no documentation in the WG about what a JWT access token would >>>>>>>> contain other than the POP work. >>>>>>>> >>>>>>>> >>>>>>>> John B. >>>>>>>> >>>>>>>> On Feb 13, 2016, at 9:18 AM, tors...@lodderstedt.net wrote: >>>>>>>> >>>>>>>> >>>>>>>> I basically support adoption of this document. Asserting >>>>>>>> authentication methods in access tokens (in this case in JWTS format) >>>>>>>> is reasonable. We use it to pass information about the authentication >>>>>>>> performed prior issuing an access token to the _resource_ server. >>>>>>>> >>>>>>>> What worries me is the back and forth between oauth and oidc. The amr >>>>>>>> claim is defined in oidc (which sits on top of oauth) but the oauth wg >>>>>>>> specifies the registry? Moreover, the current text does not give a >>>>>>>> rationale for using amr in context of oauth. >>>>>>>> >>>>>>>> As a WG we need to find a clear delineation >>>>>>>> between both protocols, otherwise noone will >>>>>>>> really understand the difference and when to >>>>>>>> use what. We create confusion! >>>>>>>> >>>>>>>> For this particular draft >>>>>>>> this means to either move amr to oauth or the registry to oidc. >>>>>>>> >>>>>>>> best regards, >>>>>>>> Torsten. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -------- Ursprüngliche >>>>>>>> Nachricht -------- >>>>>>>> Von: Roland Hedberg <roland.hedb...@umu.se> >>>>>>>> Gesendet: Friday, February 12, 2016 05:45 PM >>>>>>>> An: oauth@ietf.org >>>>>>>> Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call >>>>>>>> for Adoption Finalized >>>>>>>> >>>>>>>> +1 >>>>>>>> >>>>>>>> > 12 feb 2016 kl. 16:58 skrev John Bradley <ve7...@ve7jtb.com>: >>>>>>>> > >>>>>>>> > +1 to adopt this draft. >>>>>>>> > >>>>>>>> >> On Feb 12, 2016, at 3:07 AM, Mike Jones >>>>>>>> >> <michael.jo...@microsoft.com> wrote: >>>>>>>> >> >>>>>>>> >> Draft -05 incorporates the feedback described below - deleting the >>>>>>>> >> request parameter, noting that this spec isn't an encouragement to >>>>>>>> >> use OAuth 2.0 for >>>>>>>> >> authentication without employing appropriate >>>>>>>> >> extensions, and no longer requiring a >>>>>>>> >> specification for IANA registration. I believe that it’s now ready >>>>>>>> >> for working group adoption. >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> -- Mike >>>>>>>> >> >>>>>>>> >> -----Original Message----- >>>>>>>> >> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes >>>>>>>> >> Tschofenig >>>>>>>> >> Sent: Thursday, February 4, 2016 11:23 AM >>>>>>>> >> To: oauth@ietf.org >>>>>>>> >> Subject: [OAUTH-WG] Authentication Method Reference Values: Call >>>>>>>> >> for Adoption Finalized >>>>>>>> >> >>>>>>>> >> Hi all, >>>>>>>> >> >>>>>>>> >> On January 19th I posted a call for adoption of the Authentication >>>>>>>> >> Method Reference >>>>>>>> >> Values specification, see >>>>>>>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15402.html >>>>>>>> >> >>>>>>>> >> What surprised us is that this work is conceptually very simple: we >>>>>>>> >> define new claims and create a registry with new values. Not a big >>>>>>>> >> deal but that's not what the >>>>>>>> >> feedback from the Yokohama IETF meeting and the subsequent >>>>>>>> >> call for adoption on the list shows. The feedback lead to mixed >>>>>>>> >> feelings and it is a bit difficult for Derek and myself to judge >>>>>>>> >> consensus. >>>>>>>> >> >>>>>>>> >> Let me tell you what we see from the comments on the list. >>>>>>>> >> >>>>>>>> >> In his review at >>>>>>>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15423.html >>>>>>>> >> James Manger asks for significant changes. Among other things, he >>>>>>>> >> wants to remove one of the claims. He provides a detailed review >>>>>>>> >> and actionable items. >>>>>>>> >> >>>>>>>> >> William Denniss believes the document is ready for adoption but >>>>>>>> >> agrees with some of the comments from James. Here is his review: >>>>>>>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15426.html >>>>>>>> >> >>>>>>>> >> Justin is certainly the reviewer with the strongest opinion. Here >>>>>>>> >> is one of his posts: >>>>>>>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15457.html >>>>>>>> >> >>>>>>>> >> Among all concerns Justin expressed the following one is actually >>>>>>>> >> actionable IMHO: Justin is worried that reporting how a person >>>>>>>> >> authenticated to an authorization endpoint >>>>>>>> >> and encouraging people to use OAuth for >>>>>>>> >> authentication is a fine line. He believes that this document leads >>>>>>>> >> readers to believe the latter. >>>>>>>> >> >>>>>>>> >> John agrees with Justin in >>>>>>>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15448.html >>>>>>>> >> that we need to make sure that people are not mislead about the >>>>>>>> >> intention of the document. John also provides additional comments >>>>>>>> >> in this post to the >>>>>>>> >> list: >>>>>>>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15441.html >>>>>>>> >> Most of them require more than just editing work. For example, >>>>>>>> >> methods listed are really not useful, >>>>>>>> >> >>>>>>>> >> Phil agrees with the document adoption but has some remarks about >>>>>>>> >> the registry although he does not propose specific text. His review >>>>>>>> >> is here: >>>>>>>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15462.html >>>>>>>> >> >>>>>>>> >> With my co-chair hat on: I just wanted to clarify that registering >>>>>>>> >> claims (and values within those claims) is within the scope of the >>>>>>>> >> OAuth working group. We standardized the JWT in this group and we >>>>>>>> >> are also chartered to standardize claims, as we are currently doing >>>>>>>> >> with various drafts. Not standardizing JWT in the IETF would have >>>>>>>> >> lead to reduced interoperability and less security. I have no >>>>>>>> >> doubts that was a wrong decision. >>>>>>>> >> >>>>>>>> >> In its current form, there is not enough support to have this >>>>>>>> >> document as a WG item. >>>>>>>> >> >>>>>>>> >> We believe that the document authors should address some of the >>>>>>>> >> easier comments and submit a new version. This would allow us to >>>>>>>> >> reach out to those who had expressed concerns about the scope of >>>>>>>> >> the document to re-evaluate their decision. A new draft version >>>>>>>> >> should at least address the following issues: >>>>>>>> >> >>>>>>>> >> * Clarify that this document is not an encouragement for using >>>>>>>> >> OAuth as an authentication protocol. I believe that this would >>>>>>>> >> address some of the concerns raised by Justin and John. >>>>>>>> >> >>>>>>>> >> * Change the registry policy, which would address one of the >>>>>>>> >> comments from James, William, and Phil. >>>>>>>> >> >>>>>>>> >> Various other items require discussion since they are more >>>>>>>> >> difficult to address. For example, John noted that he does not like >>>>>>>> >> the use of request parameters. Unfortunately, no alternative is >>>>>>>> >> offered. I urge John to provide an alternative proposal, if there >>>>>>>> >> is one. Also, the remark that the values are meaningless could be >>>>>>>> >> countered with an alternative proposal. James wanted to remove the >>>>>>>> >> "amr_values" parameter. >>>>>>>> >> Is this what others want as well? >>>>>>>> >> >>>>>>>> >> After these items have been addressed we believe that more folks in >>>>>>>> >> the group will support the document. >>>>>>>> >> >>>>>>>> >> Ciao >>>>>>>> >> Hannes & Derek >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> _______________________________________________ >>>>>>>> >> OAuth mailing list >>>>>>>> >> OAuth@ietf.org >>>>>>>> >> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> > >>>>>>>> > _______________________________________________ >>>>>>>> > OAuth mailing list >>>>>>>> > OAuth@ietf.org >>>>>>>> > https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >>>>>>>> — Roland >>>>>>>> >>>>>>>> ”Everybody should be quiet near a little stream and listen." >>>>>>>> >From ’Open House for Butterflies’ by Ruth Krauss >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
