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
