+1 Those login and logout ceremonies giving false impression of security probably will diminish its importance pretty quickly. I recon those more as a privacy feature than security. 2016年2月16日(火) 9:35 Phil Hunt (IDM) <phil.h...@oracle.com>:
> +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 <jric...@mit.edu> >>> Sent: 2/13/2016 11:11 AM >>> To: Phil Hunt <phil.h...@oracle.com> >>> >>> Cc: <oauth@ietf.org><oauth@ietf.org> <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" <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> >>> michael.jo...@microsoft.com> >>> An: tors...@lodderstedt.net,John Bradley < <ve7...@ve7jtb.com> >>> 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 [ <oauth-boun...@ietf.org>mailto:oauth-boun...@ietf.org >>> <oauth-boun...@ietf.org>] *On Behalf Of * <tors...@lodderstedt.net> >>> tors...@lodderstedt.net >>> *Sent:* Saturday, February 13, 2016 6:37 AM >>> *To:* John Bradley < <ve7...@ve7jtb.com>ve7...@ve7jtb.com> >>> *Cc:* <oauth@ietf.org>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>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> >>> 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>roland.hedb...@umu.se> >>> Gesendet: Friday, February 12, 2016 05:45 PM >>> An: <oauth@ietf.org>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> >>> ve7...@ve7jtb.com>: >>> > >>> > +1 to adopt this draft. >>> > >>> >> On Feb 12, 2016, at 3:07 AM, Mike Jones < >>> <michael.jo...@microsoft.com>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 [ <oauth-boun...@ietf.org>mailto:oauth-boun...@ietf.org >>> <oauth-boun...@ietf.org>] On Behalf Of Hannes Tschofenig >>> >> Sent: Thursday, February 4, 2016 11:23 AM >>> >> To: <oauth@ietf.org>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> >>> 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> >>> 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> >>> 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> >>> 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> >>> 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> >>> 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> >>> 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>OAuth@ietf.org >>> >> <https://www.ietf.org/mailman/listinfo/oauth> >>> https://www.ietf.org/mailman/listinfo/oauth >>> > >>> > _______________________________________________ >>> > OAuth mailing list >>> > <OAuth@ietf.org>OAuth@ietf.org >>> > <https://www.ietf.org/mailman/listinfo/oauth> >>> 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>OAuth@ietf.org >>> <https://www.ietf.org/mailman/listinfo/oauth> >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> <OAuth@ietf.org>OAuth@ietf.org >>> <https://www.ietf.org/mailman/listinfo/oauth> >>> 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 listOAuth@ietf.orghttps://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
