Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
Phil, There are four standard session ending controls. 1) Logout 2) Idle session timeout 3) Absolute timeout 4) Forced re-authentication I think these are still important and tend to not get full attention from the OAuth/OIDC crowd. :) But the OAuth 2 standard in particular is a framework - not a standard - which can be implemented many ways, of course. Aloha, -- Jim Manico @Manicode > On Feb 15, 2016, at 5:34 PM, Phil Hunt (IDM) wrote: > > 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 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 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 >>>> 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 >>>>> 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: >>>>>> Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for >>>>>> Adoption Finalized >>>>>> >>>>>> Can we just do that, then? Seems to be the e
Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
+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) : > +1 > > > Phil > > On Feb 15, 2016, at 16:50, John Bradley 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 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 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 > > 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: >>> Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call >>> for Adoption Fi
Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
+1 Phil > On Feb 15, 2016, at 16:50, John Bradley 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 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 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 >>>> 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 >>>>>> 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
Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
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 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 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 >>> 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 >>>>> 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: >>>>> 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) >>>>>> wrote: >>>>>> >>>>>> Yes >>>>>> >>>>>> Phil >>>>>> >>>>>> On Feb 13, 2016, at 07:59, "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) >>>>>>> >
Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
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 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 <mailto: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 >> >> <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 >> mailto: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 >> <mailto: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 <mailto:jric...@mit.edu> >>> Sent: 2/13/2016 11:11 AM >>> To: Phil Hunt <mailto:phil.h...@o
Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
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 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 >> 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 >>> 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: >>>> 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) >>>>> wrote: >>>>> >>>>> Yes >>>>> >>>>> Phil >>>>> >>>>> On Feb 13, 2016, at 07:59, "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 >>>>>> An: tors...@lodderstedt.net,John Bradley >>>>>> 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 >>>>
Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
I meant William - sorry! Originalnachricht Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized Von: Torsten Lodderstedt An: William Denniss ,Mike Jones Cc: "" >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 >> mailto: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 <mailto:jric...@mit.edu> >> Sent: 2/13/2016 11:11 AM >> To: Phil Hunt <mailto:phil.h...@oracle.com> >> >> Cc: <mailto: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) >>> mailto:phil.h...@oracle.com>> wrote: >>> >>> Yes >>> >>> Phil >>> >>> On Feb 13, 2016, at 07:59, "tors...@lodderstedt.net >>> <mailto:tors...@lodderstedt.net>" >> <mailto: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 >>> <mailto:michael.jo...@microsoft.com>> >>>> An: tors...@lodderstedt.net >>>> <mailto:tors...@lodderstedt.net>,John Bradley >>> <mailto:ve7...@ve7jtb.com>> >>>> Cc: oauth@ietf.org <mailto: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 <mailto:tors...@lodderstedt.net> >>>> *Sent:* Saturday, February 13, 2016 6:37 AM >>>> *To:* John Bradley mailto:ve7...@ve7jtb.com>> >>>> *Cc:* oauth@ietf.org <mailto: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
Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
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
mailto: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 <mailto:jric...@mit.edu>
Sent: 2/13/2016 11:11 AM
To: Phil Hunt <mailto:phil.h...@oracle.com>
Cc: <mailto: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)
mailto:phil.h...@oracle.com>> wrote:
Yes
Phil
On Feb 13, 2016, at 07:59, "tors...@lodderstedt.net
<mailto:tors...@lodderstedt.net>" mailto: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 mailto:michael.jo...@microsoft.com>>
An: tors...@lodderstedt.net
<mailto:tors...@lodderstedt.net>,John Bradley mailto:ve7...@ve7jtb.com>>
Cc: oauth@ietf.org <mailto: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 <mailto:tors...@lodderstedt.net>
*Sent:* Saturday, February 13, 2016 6:37 AM
*To:* John Bradley mailto:ve7...@ve7jtb.com>>
*Cc:* oauth@ietf.org <mailto: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 mailto:ve7...@ve7jtb.com>>
An: tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>
Cc: roland.hedb...@umu.se,oauth@ietf.org
<mailto: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
Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
Le dim. 14 févr. 2016 02:40, William Denniss a écrit : > On Sat, Feb 13, 2016 at 12:19 PM, Mike Jones > 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. > +1 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
We’re a standard body working group. We don’t do “efficient”. ;) — Justin > On Feb 13, 2016, at 3:19 PM, Mike Jones 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. > > -- Mike > From: Justin Richer <mailto:jric...@mit.edu> > Sent: 2/13/2016 11:11 AM > To: Phil Hunt <mailto:phil.h...@oracle.com> > Cc: <mailto: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) > <mailto:phil.h...@oracle.com>> wrote: >> >> Yes >> >> Phil >> >> On Feb 13, 2016, at 07:59, "tors...@lodderstedt.net >> <mailto:tors...@lodderstedt.net>" > <mailto: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 >> <mailto:michael.jo...@microsoft.com>> >>> An: tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>,John Bradley >>> mailto:ve7...@ve7jtb.com>> >>> Cc: oauth@ietf.org <mailto: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 <mailto:oauth-boun...@ietf.org>] >>> On Behalf Of tors...@lodderstedt.net <mailto:tors...@lodderstedt.net> >>> Sent: Saturday, February 13, 2016 6:37 AM >>> To: John Bradley mailto:ve7...@ve7jtb.com>> >>> Cc: oauth@ietf.org <mailto: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 mailto:ve7...@ve7jtb.com>> >>> An: tors...@lodderstedt.net <mailto:tors...@lodderstedt.net> >>> Cc: roland.hedb...@umu.se,oauth@ietf.org >>> <mailto: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 pa
Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
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. -- Mike From: Justin Richer<mailto:jric...@mit.edu> Sent: 2/13/2016 11:11 AM To: Phil Hunt<mailto:phil.h...@oracle.com> Cc: <mailto: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) mailto:phil.h...@oracle.com>> wrote: Yes Phil On Feb 13, 2016, at 07:59, "tors...@lodderstedt.net<mailto:tors...@lodderstedt.net>" mailto: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 mailto:michael.jo...@microsoft.com>> An: tors...@lodderstedt.net<mailto:tors...@lodderstedt.net>,John Bradley mailto:ve7...@ve7jtb.com>> Cc: oauth@ietf.org<mailto: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<mailto:tors...@lodderstedt.net> Sent: Saturday, February 13, 2016 6:37 AM To: John Bradley mailto:ve7...@ve7jtb.com>> Cc: oauth@ietf.org<mailto: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 mailto:ve7...@ve7jtb.com>> An: tors...@lodderstedt.net<mailto:tors...@lodderstedt.net> Cc: roland.hedb...@umu.se,oauth@ietf.org<mailto: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<mailto: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 betw
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) wrote: > > Yes > > Phil > > On Feb 13, 2016, at 07:59, "tors...@lodderstedt.net > <mailto:tors...@lodderstedt.net>" <mailto: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 > <mailto:michael.jo...@microsoft.com>> >> An: tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>,John Bradley >> mailto:ve7...@ve7jtb.com>> >> Cc: oauth@ietf.org <mailto: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 <mailto:oauth-boun...@ietf.org>] >> On Behalf Of tors...@lodderstedt.net <mailto:tors...@lodderstedt.net> >> Sent: Saturday, February 13, 2016 6:37 AM >> To: John Bradley mailto:ve7...@ve7jtb.com>> >> Cc: oauth@ietf.org <mailto: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 mailto:ve7...@ve7jtb.com>> >> An: tors...@lodderstedt.net <mailto:tors...@lodderstedt.net> >> Cc: roland.hedb...@umu.se,oauth@ietf.org >> <mailto: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 >> <mailto: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 authe
Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
Yes Phil > On Feb 13, 2016, at 07:59, "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 > An: tors...@lodderstedt.net,John Bradley > 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 > 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 > 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 > 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 : > > > > +1 to adopt this draft. > > > >> On Feb 12, 2016, at 3:07 AM, Mike Jones > >> wrote: > >> >
Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
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 An: tors...@lodderstedt.net,John Bradley 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 >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 mailto:ve7...@ve7jtb.com>> >An: tors...@lodderstedt.net<mailto:tors...@lodderstedt.net> >Cc: >roland.hedb...@umu.se,oauth@ietf.org<mailto: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<mailto: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 mailto:roland.hedb...@umu.se>> >Gesendet: Friday, February 12, 2016 05:45 PM >An: oauth@ietf.org<mailto: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 >> mailto:ve7...@ve7jtb.com>>: >> >> +1 to adopt this draft. >> >>> On Feb 12, 2016, at 3:07 AM, Mike Jones >>> mailto: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
Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
I was trying to say that the issue about other specs using the JWT registry is not specific to OIDC. Discovery is a separate issue. If we don’t adopt this document it could go as AD sponsored , but I don’t think that really addresses your issue. The distinction between AD sponsored and WG document will be lost on any normal person. Remember that the amr claim is already in the registry registered by the OIDF. http://www.iana.org/assignments/jwt/jwt.xhtml <http://www.iana.org/assignments/jwt/jwt.xhtml> This discussion is about if there should be a IANA registry for the claim values and where it should be. If we want to keep the values registries and the claims together then it should be in the WG. If not then it can be AD sponsored and a separate IANA registry. As I understand it doing it as a OIDF document would not allow for an IANA registry and the OIDF would need to run the registry due to IANA policy. John B. > On Feb 13, 2016, at 11:36 AM, tors...@lodderstedt.net wrote: > > 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 > 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 >> <mailto: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 mailto:roland.hedb...@umu.se>> >> Gesendet: Friday, February 12, 2016 05:45 PM >> An: oauth@ietf.org <mailto: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 > > <mailto:ve7...@ve7jtb.com>>: >> > >> > +1 to adopt this draft. >> > >> >> On Feb 12, 2016, at 3:07 AM, Mike Jones > >> <mailto: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 re
Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
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 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 mailto:ve7...@ve7jtb.com>> An: tors...@lodderstedt.net<mailto:tors...@lodderstedt.net> Cc: roland.hedb...@umu.se,oauth@ietf.org<mailto: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<mailto: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 mailto:roland.hedb...@umu.se>> Gesendet: Friday, February 12, 2016 05:45 PM An: oauth@ietf.org<mailto: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 > mailto:ve7...@ve7jtb.com>>: > > +1 to adopt this draft. > >> On Feb 12, 2016, at 3:07 AM, Mike Jones >> mailto: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<mailto: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 Authen
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 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 >> 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 : >> > >> > +1 to adopt this draft. >> > >> >> On Feb 12, 2016, at 3:07 AM, Mike Jones >> >> 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 >> >> consensu
Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
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 > 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 : > > > > +1 to adopt this draft. > > > >> On Feb 12, 2016, at 3:07 AM, Mike Jones > >> 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 endpoin
Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
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 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 : >> >> +1 to adopt this draft. >> >>> On Feb 12, 2016, at 3:07 AM, Mike Jones 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
Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
+1 > 12 feb 2016 kl. 16:58 skrev John Bradley : > > +1 to adopt this draft. > >> On Feb 12, 2016, at 3:07 AM, Mike Jones 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 >&
Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
+1 to adopt this draft. > On Feb 12, 2016, at 3:07 AM, Mike Jones wrote: > > Draft -05 <http://tools.ietf.org/html/draft-jones-oauth-amr-values-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 > <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 regist
Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
Thanks Mike. Phil > On Feb 11, 2016, at 22:07, Mike Jones 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
Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
Draft -05<http://tools.ietf.org/html/draft-jones-oauth-amr-values-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-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 signature.asc Description: OpenPGP digital signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
