Re: [OAUTH-WG] State Leakage Attack

[tors...@lodderstedt.net]

Understood. Thanks.

So this is basically a way to circumvent XSRF protection. OWASP has an 
excellent description of the attack and mitigations 
https://www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet - It recommends 
per-request CSRF tokens for state changes via GET requests. Same conclusion:-)

 Ursprüngliche Nachricht 
Von: Thomas Broyer <t.bro...@gmail.com>
Gesendet: Saturday, April 23, 2016 10:46 PM
An: Torsten Lodderstedt <tors...@lodderstedt.net>,Guido Schmitz 
<g.schm...@gtrs.de>,oauth@ietf.org
Betreff: Re: [OAUTH-WG] State Leakage Attack

>On Sat, Apr 23, 2016 at 3:56 PM Torsten Lodderstedt <tors...@lodderstedt.net>
>wrote:
>
>> I don't think this is possible if the client checks whether the state
>> actually belongs to its local session before it processes it.
>>
>
>It does so in step 3 below, and it accepts it because: a) the value is the
>same, as it leaked and the attacker reinjected the leaked value, and b) the
>client didn't invalidate the value after first use in step 1.
>
>
>> Am 23.04.2016 um 15:53 schrieb Thomas Broyer:
>>
>>
>>
>> On Sat, Apr 23, 2016 at 12:57 PM Torsten Lodderstedt <
>> tors...@lodderstedt.net> wrote:
>>
>>> Hi Guido,
>>>
>>> do I get it right. The attacker is supposed to use the state value in
>>> order to overwrite the user agent's session state?
>>>
>>
>> Most apps only ever remember a single access token, so by re-using the
>> state the attacker could override the access token by injecting an
>> authorization code at the redirection_uri, tricking it to accepting the
>> request by injecting a known (leaked) "state" value.
>>
>> Flow is:
>> 1. victim app makes a normal OAuth code flow but:
>> 1a. doesn't invalidate the "state" upon return, making it reusable
>> 1b. leaks the "state" to the attacker
>> It stores the access token into the session.
>> 2. attacker starts a normal OAuth code flow, using the victim app's
>> redirect_uri, and "intercepts" the "code", which it injects to the victim
>> app's redirection endpoint, along with the leaked state, through the victim
>> user's browser. Note that the "code" is bound to the attacker's account.
>> 3. the victim app, validates the "state" and accepts the request, so it
>> exchanges the code for an access token, and stores it in its session,
>> replacing the previous one. This means that the victim's session now uses
>> an access token that's actually bound to the attacker's account.
>>
>> Easy mitigation is to have one-time state values (i.e. state is somehow
>> bound to the authorization request, not just the "user session")
>>
>> Furthermore, IFF the original OAuth code flow was in error (for whichever
>> reason) and/or was tricked to a bad redirect_uri (like in Homakov's code
>> leak attack) such that no "code" is redeemed; then the attacker could
>> possibly use this to link the victim user's account at the victim app to
>> the attacker's account at the AS (relying on inexistant association of
>> accounts at the victim app and AS), allowing the attacker to authenticate
>> to the victim user's account on the victim app using the attacker's
>> credentials (well-known social login / linked accounts attack).
>>
>>
>>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] State Leakage Attack

[tors...@lodderstedt.net]

Hi Daniel,

how is the attackers supposed to utilise the leaked state value? I would assume 
the legit client binds it to a certain user agent, e.g. via the session 
context, which is not available to the attacker.

best regards,
Torsten.

 Originalnachricht 
Betreff: Re: [OAUTH-WG] State Leakage Attack
Von: Daniel Fett 
An: Antonio Sanso 
Cc: Guido Schmitz ,oauth@ietf.org,Ralf 
Kuesters 

>Am 22.04.2016 um 16:39 schrieb Antonio Sanso:
>> hi Daniel
>> 
>> On Apr 22, 2016, at 4:35 PM, Daniel Fett > > wrote:
>> 
>>> Hi Antonio,
>>>
>>> Am 22.04.2016 um 16:30 schrieb Antonio Sanso:
> Hi all,
>
> During our formal analysis of OAuth we found an attack that allows
> CSRF. It is similar to the "code" leak described by Homakov in [1] and
> therefore not really surprising. In this attack, the intention for an
> attacker is to steal the "state" value instead of the "code" value.
>
> Setting:
>
> In the auth code grant, after authentication to the AS, the user is
> redirected to some page on the Client. If this page leaks the
> referrer, i.e., there is a link to the attacker's website or some
> resource is loaded from the attacker, then the attacker can see not
> only code but also state in the Referer header of the request.
>
> The fact that code can leak was described in [1]. Since code is
> single-use, it might be already redeemed in most cases when it is sent
> to the attacker.

 probably is not redeemed instead, just because the redirect_uri is
 not the correct one.
 The mitigation that good implemented AS use (also Github) is to
 follow section 4.1.3 the OAuth core specification [RFC6749], in
 particular:

 "ensure that the "redirect_uri" parameter is present if the
 "redirect_uri" parameter was included in the initial authorization
 request as described in Section 4.1.1, and if included ensure that
 their values are identical."
>>>
>>> The attack is not based on a manipulation of the redirect_uri. Instead,
>>> a correct redirect_uri is used, but the page loaded from the
>>> redirect_uri contains links or external resources (intentionally or not).
>> 
>> right. so is not really [1] :) since there there is manipulation using
>> /../../ 
>
>Of course.
>
>> Now the real question why a legit redirect_uri should contain links to
>> malicious external resources?
>
>Well, why not? :)
>
>Anyway, developers should be made aware that having external
>resources/links on these pages is a bad idea.
>
>- Daniel
>
>-- 
>Informationssicherheit und Kryptografie
>Universität Trier - Tel. 0651 201 2847 - H436
>
>___
>OAuth mailing list
>OAuth@ietf.org
>https://www.ietf.org/mailman/listinfo/oauth
>___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Meeting Minutes

[tors...@lodderstedt.net]

Different people, different perceptions :-)

But anyway, the discussion on the list has already started, right?

 Originalnachricht 
Betreff: Re: [OAUTH-WG] Meeting Minutes
Von: Hannes Tschofenig <hannes.tschofe...@gmx.net>
An: Brian Campbell <bcampb...@pingidentity.com>,Torsten Lodderstedt 
<tors...@lodderstedt.net>
Cc: oauth@ietf.org

>Hi Torsten,
>
>On 04/19/2016 12:34 AM, Brian Campbell wrote:
>>
>> I felt some consensous around the topic that in the end, there must be
>> normative chances to the core protocol and the respective security
>> considerations.
>>
>> Barry gave his advice regarding updates in this context.
>
>There was no consensus on this topic during the meeting and, in
>addition, we have to consult those on the mailing list as well.
>
>Barry, in my understanding, outlined the different options we have at
>the meeting.
>
>
>Ciao
>Hannes
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.1

[tors...@lodderstedt.net]

And what about code injection and open redirectors? I think we already have a 
lot of deployment experience that should be used to evolve the spec.

Sent by MailWise – See your emails as clean, short chats.

 Originalnachricht 
Betreff: Re: [OAUTH-WG] OAuth 2.1
Von: "Phil Hunt (IDM)" <phil.h...@oracle.com>
An: Mike Jones <michael.jo...@microsoft.com>
Cc: Torsten Lodderstedt <tors...@lodderstedt.net>,oauth@ietf.org

>I believe all we need is a new draft that deals with the new "dynamic/mix-up" 
>cases as these were not considered in the original spec process. 
>
>The updated by method works best for this. It also consolidates a lot of 
>piecemeal specs into one consistent spec. 
>
>Phil
>
>> On Apr 7, 2016, at 15:25, Mike Jones <michael.jo...@microsoft.com> wrote:
>> 
>> Yes - an intentionally conservative, implementation- and experience-driven 
>> path.
>> 
>> Revising OAuth 2.0 is a *big deal*.  We shouldn't even be talking about it 
>> until we've completed steps 1-5 below - *including* the "iterate" step, as 
>> necessary.  If we get this wrong, we'll fragment OAuth, which is a terrible 
>> and irresponsible outcome we should consciously avoid at all costs.
>> 
>> In particular, we should not recharter for an OAuth 2.1 until we already 
>> know what will be in it and know from deployment experience that it's the 
>> right stuff.
>> 
>>-- Mike
>> 
>> -Original Message-
>> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] 
>> Sent: Thursday, April 7, 2016 3:16 PM
>> To: Mike Jones <michael.jo...@microsoft.com>
>> Cc: Samuel Erdtman <sam...@erdtman.se>; Anthony Nadalin 
>> <tony...@microsoft.com>; oauth@ietf.org
>> Subject: Re: [OAUTH-WG] OAuth 2.1
>> 
>> Hi Mike,
>> 
>> in my opinion, you described a possible path towards 2.1. Would you agree?
>> 
>> best regards,
>> Torsten.
>> 
>>> Am 07.04.2016 um 13:38 schrieb Mike Jones <michael.jo...@microsoft.com>:
>>> 
>>> I am strongly against creating a 2.1 spec until we have at least a year of 
>>> deployment experience with the contents we're adding to 2.0, so as not to 
>>> fragment the OAuth marketplace.
>>> 
>>> I think we should:
>>> 1.  Continue working on new security mitigations in new drafts (such 
>>> as mix-up-mitigation, etc.) that add features to use with 2.0 2.  
>>> Continue working on PoP specs (such as pop-key-distribution, etc.) 
>>> that add features to use with 2.0 3.  Continue working on other new 
>>> specs (such as discovery, resource-indicators, etc.) that add features 
>>> to use with 2.0 4.  Learn from deployment experience with all of them 
>>> 5.  Iterate if the deployment experience tells us that we need to
>>> 
>>> Only after we believe we have all the features right and we know that they 
>>> work together well should we consider creating a 2.1.  If we rush to a 2.1 
>>> and get it wrong, we'll lose developers' trust and we'll never get it back.
>>> 
>>>   -- Mike
>>> 
>>> -Original Message-
>>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Samuel 
>>> Erdtman
>>> Sent: Thursday, April 7, 2016 12:48 PM
>>> To: Anthony Nadalin <tony...@microsoft.com>
>>> Cc: oauth@ietf.org
>>> Subject: Re: [OAUTH-WG] OAuth 2.1
>>> 
>>> +1 on a 2.1 version
>>> 
>>> -1 on defining scopes more precisely in 2.1
>>> 
>>> Sent from my iPhone
>>> 
>>>> On 7 apr. 2016, at 14:46, Anthony Nadalin <tony...@microsoft.com> wrote:
>>>> 
>>>> I don't belive that scopes should be defined more precisely as this 
>>>> opaqueness was a design feature, I'm not seeing the reason why scopes need 
>>>> to be defined, as these are application specific.
>>>> 
>>>> -Original Message-
>>>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten 
>>>> Lodderstedt
>>>> Sent: Thursday, April 7, 2016 5:32 AM
>>>> To: George Fletcher <gffle...@aol.com>
>>>> Cc: oauth@ietf.org
>>>> Subject: Re: [OAUTH-WG] OAuth 2.1
>>>> 
>>>> Hi all,
>>>> 
>>>> as I already said in the meeting: I would very much prefer to have an 
>>>> extension/update of RFC 6819 covering all "new" threats, including:
>>>> - mix up
>>>> - code injection aka copy

Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-resource-indicators-01.txt

[tors...@lodderstedt.net]

Hi Brian,

I assume resource server ids or URIs to be a names namespace for scope values 
or that scope values are be bound to certain resource servers. It seems you 
have less coupling in mind?

Best regards,
Torsten.

Sent by MailWise – See your emails as clean, short chats.

 Originalnachricht 
Betreff: Re: [OAUTH-WG] Fwd: New Version Notification for 
draft-campbell-oauth-resource-indicators-01.txt
Von: Brian Campbell <bcampb...@pingidentity.com>
An: Torsten Lodderstedt <tors...@lodderstedt.net>
Cc: oauth <oauth@ietf.org>

>Sorry for the slow response, Torsten, I was on vacation last week with my
>family.
>
>The omission of scope values in the example requests wasn't really
>intentional so much as just an initial desire to have a minimal amount of
>stuff in the examples. Adding a scope parameter to the example
>authorization request (Figure 1) would probably be a good thing to do. I'll
>make a note to do so.
>
>As far as the relationship between scope and resource. Scope is *what*
>access is being requested/granted. And resource is about *where* a
>particular access token will be used. I envision resource as allowing for
>scope to
>
>Note that, as currently written anyway, resource is unlike scope in that
>it's not something that the end-user approves or denies access to and it's
>not something that is persisted with the grant. It only informs the access
>token being requested at the time. So it'd be used at the token endpoint
>when getting an access token. And only at the authorization endpoint when
>an access token will come back directly in the authorization response
>(implicit flows).
>
>Currently, yes, multiple resources are allowed by the draft to indicate
>multiple RSs.  Though there's a note in there questioning it because it
>complicates things in some situations where different token content or
>encryption is needed for different RSs that are asked for in the same
>request.
>
>
>
>On Sat, Apr 2, 2016 at 8:04 AM, Torsten Lodderstedt <tors...@lodderstedt.net
>> wrote:
>
>> Hi Brian,
>>
>> did you intentionally omit scope values in your example requests? I would
>> like to know what you envision to be the relationshop between scope and
>> resource.
>>
>> As you draft says, we today use scope values to indicate to the AS, which
>> ressource servers the clients wants to access. I think we nearly
>> exclusively use it for that purpose and only seldomly to request certain
>> access rights. One of the advantages is, we can request access to multiple
>> resource servers simple by putting multiple scope values into the scope
>> parameter. Will this be possible with the extension you are proposing?
>>
>> Best regards,
>> Torsten.
>>
>> Am 21.03.2016 um 18:41 schrieb Brian Campbell <bcampb...@pingidentity.com
>> >:
>>
>> Very minor update to this draft before the deadline that moves Hannes from
>> Acknowledgements to Authors in acknowledgment of his similar work a few
>> years ago. Also fleshed out the IANA section with the formal registration
>> requests.
>>
>>
>> -- Forwarded message --
>> From: <internet-dra...@ietf.org>
>> Date: Mon, Mar 21, 2016 at 11:31 AM
>> Subject: New Version Notification for
>> draft-campbell-oauth-resource-indicators-01.txt
>> To: Hannes Tschofenig <hannes.tschofe...@gmx.net>, Hannes Tschofenig <
>> hannes.tschofe...@gmx.net>, Brian Campbell <brian.d.campb...@gmail.com>,
>> John Bradley <ve7...@ve7jtb.com>
>>
>>
>>
>> A new version of I-D, draft-campbell-oauth-resource-indicators-01.txt
>> has been successfully submitted by Brian Campbell and posted to the
>> IETF repository.
>>
>> Name:   draft-campbell-oauth-resource-indicators
>> Revision:   01
>> Title:  Resource Indicators for OAuth 2.0
>> Document date:  2016-03-21
>> Group:  Individual Submission
>> Pages:  8
>> URL:
>> https://www.ietf.org/internet-drafts/draft-campbell-oauth-resource-indicators-01.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/
>> Htmlized:
>> https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01
>> Diff:
>> https://www.ietf.org/rfcdiff?url2=draft-campbell-oauth-resource-indicators-01
>>
>> Abstract:
>>This straw-man specification defines an extension to The OAuth 2.0
>>Authorization Framework that enables the client and authorization
>>server to more explicitly to communicate about the protected
>>resource(s) to be accessed.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

[tors...@lodderstedt.net]

I meant William - sorry!

 Originalnachricht 
Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for 
Adoption Finalized
Von: Torsten Lodderstedt <tors...@lodderstedt.net>
An: William Denniss <wdenn...@google.com>,Mike Jones 
<michael.jo...@microsoft.com>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>

>Hi Denniss,
>
>out of curiosity: Does Google use amr values?
>
>best regards,
>Torsten.
>
>Am 14.02.2016 um 02:40 schrieb William Denniss:
>>
>>
>> On Sat, Feb 13, 2016 at 12:19 PM, Mike Jones 
>> <michael.jo...@microsoft.com <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: <oauth@ietf.org> <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)
>>> <phil.h...@oracle.com <mailto:phil.h...@oracle.com>> wrote:
>>>
>>> Yes
>>>
>>> Phil
>>>
>>> On Feb 13, 2016, at 07:59, "tors...@lodderstedt.net
>>> <mailto:tors...@lodderstedt.net>" <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 <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>
>>&g

Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

[tors...@lodderstedt.net]

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 
>>> 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 

Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

[tors...@lodderstedt.net]

We clearly have this problem between oauth and oidc. Just take a look at the 
discovery thread.

According to you argument I see two options:
(1) amr stays an oidc claim, is used in oidc only and the oauth wg just 
publishes the registry entries. In this case, the spec should clearly explain 
this.
(2) amr is of any use in oauth (although it has been invented in oidc) - than 
define it and motivate it's use in oauth in this spec. 

Right now, I think it creates the impression oauth is for authentication. 

 Originalnachricht 
Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for 
Adoption Finalized
Von: John Bradley <ve7...@ve7jtb.com>
An: tors...@lodderstedt.net
Cc: roland.hedb...@umu.se,oauth@ietf.org

>This is not a issue between oauth and OIDC.
>
>This has to do with the registry for JWT being in OAuth.   Many protocols that 
>use JWT are going to want to register claims.  
>We can’t ask them to all move the parts of there specs that use JWT to OAuth.
>
>Perhaps JWT should have been part of JOSE, but that is water under the bridge. 
> 
>
>The OAuth WG is responsible for JWT and it’s registry, and we will need to 
>deal with registering claims.  
>
>I guess that we can tell people that they need to publish the specs defining 
>the claims someplace else, and just do the registry part.
>However doing that will probably not improve interoperability and 
>understanding.
>
>This document defines the claim for JWT in general.  We still have almost no 
>documentation in the WG about what a JWT access token would contain other than 
>the POP work.
>
>John B.
>> On Feb 13, 2016, at 9:18 AM, tors...@lodderstedt.net wrote:
>> 
>> I basically support adoption of this document. Asserting authentication 
>> methods in access tokens (in this case in JWTS format) is reasonable. We use 
>> it to pass information about the authentication performed prior issuing an 
>> access token to the _resource_ server.
>> 
>> What worries me is the back and forth between oauth and oidc. The amr claim 
>> is defined in oidc (which sits on top of oauth) but the oauth wg specifies 
>> the registry? Moreover, the current text does not give a rationale for using 
>> amr in context of oauth.
>> 
>> As a WG we need to find a clear delineation between both protocols, 
>> otherwise noone will really understand the difference and when to use what. 
>> We create confusion!
>> 
>> For this particular draft this means to either move amr to oauth or the 
>> registry to oidc.
>> 
>> best regards, 
>> Torsten.
>> 
>> 
>> 
>>  Ursprüngliche Nachricht 
>> Von: Roland Hedberg <roland.hedb...@umu.se>
>> Gesendet: Friday, February 12, 2016 05:45 PM
>> An: oauth@ietf.org
>> Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for 
>> Adoption Finalized
>> 
>> +1
>> 
>> > 12 feb 2016 kl. 16:58 skrev John Bradley <ve7...@ve7jtb.com>:
>> > 
>> > +1 to adopt this draft.
>> > 
>> >> On Feb 12, 2016, at 3:07 AM, Mike Jones <michael.jo...@microsoft.com> 
>> >> wrote:
>> >> 
>> >> Draft -05 incorporates the feedback described below - deleting the 
>> >> request parameter, noting that this spec isn't an encouragement to use 
>> >> OAuth 2.0 for authentication without employing appropriate extensions, 
>> >> and no longer requiring a specification for IANA registration.  I believe 
>> >> that it’s now ready for working group adoption.
>> >> 
>> >>   -- Mike
>> >> 
>> >> -Original Message-
>> >> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
>> >> Sent: Thursday, February 4, 2016 11:23 AM
>> >> To: oauth@ietf.org
>> >> Subject: [OAUTH-WG] Authentication Method Reference Values: Call for 
>> >> Adoption Finalized
>> >> 
>> >> Hi all,
>> >> 
>> >> On January 19th I posted a call for adoption of the Authentication Method 
>> >> Reference Values specification, see 
>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15402.html
>> >> 
>> >> What surprised us is that this work is conceptually very simple: we 
>> >> define new claims and create a registry with new values. Not a big deal 
>> >> but that's not what the feedback from the Yokohama IETF meeting and the 
>> >> subsequent call for adoption on the list shows. The feedback lead to 
>> >> mix

Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

[tors...@lodderstedt.net]

So basically, the RFC could also just establish the new registry and oidf could 
feel in the values?

(just trying to understand)

 Originalnachricht 
Betreff: RE: [OAUTH-WG] Authentication Method Reference Values: Call for 
Adoption Finalized
Von: Mike Jones <michael.jo...@microsoft.com>
An: tors...@lodderstedt.net,John Bradley <ve7...@ve7jtb.com>
Cc: oauth@ietf.org

>The context that most people on this thread probably don’t have is that an 
>IANA registry can only be established by an RFC.  Non-RFC specifications, such 
>as OpenID specifications, can *register* values in a registry, but they cannot 
>*establish* a registry.  The OpenID Foundation inquired about this with the 
>IETF before OpenID Connect was finalized and learned that its specifications 
>could not establish IANA registries.  Otherwise, they would have.
>
>Instead, RFCs need to be created to establish registries – even for values 
>first defined in non-RFC specifications.  This specification is one example of 
>doing this.
>
>  -- Mike
>
>From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of 
>tors...@lodderstedt.net
>Sent: Saturday, February 13, 2016 6:37 AM
>To: John Bradley <ve7...@ve7jtb.com>
>Cc: oauth@ietf.org
>Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for 
>Adoption Finalized
>
>
>We clearly have this problem between oauth and oidc. Just take a look at the 
>discovery thread.
>
>According to you argument I see two options:
>(1) amr stays an oidc claim, is used in oidc only and the oauth wg just 
>publishes the registry entries. In this case, the spec should clearly explain 
>this.
>(2) amr is of any use in oauth (although it has been invented in oidc) - than 
>define it and motivate it's use in oauth in this spec.
>
>Right now, I think it creates the impression oauth is for authentication.
>
>
> Originalnachricht 
>Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for 
>Adoption Finalized
>Von: John Bradley <ve7...@ve7jtb.com<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.