In older systems, time based logout is all you have if you aren't assessing risk.
I would think over time will quickly diminish in its importance (or as best practice) - at least as the single method for determine a session should end other than explicit logout. Phil > On Feb 15, 2016, at 16:22, 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
