So basically, the RFC could also just establish the new registry
and oidf could feel in the values?
(just trying to understand)
-------- Originalnachricht --------
Betreff: RE: [OAUTH-WG] Authentication Method Reference Values:
Call for Adoption Finalized
Von: Mike Jones <michael.jo...@microsoft.com
<mailto:michael.jo...@microsoft.com>>
An: tors...@lodderstedt.net
<mailto:tors...@lodderstedt.net>,John Bradley <ve7...@ve7jtb.com
<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 <ve7...@ve7jtb.com <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 <ve7...@ve7jtb.com <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 <roland.hedb...@umu.se
<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
<ve7...@ve7jtb.com <mailto:ve7...@ve7jtb.com>>:
>
> +1 to adopt this draft.
>
>> On Feb 12, 2016, at 3:07 AM, Mike Jones
<michael.jo...@microsoft.com
<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
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 <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
— Roland
”Everybody should be quiet near a little stream and listen."
>From ’Open House for Butterflies’ by Ruth Krauss
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
