Re: [OAUTH-WG] [Errata Held for Document Update] RFC6819 (4267)

[Phil Hunt (IDM)]

+1

Phil

> On Dec 17, 2015, at 15:00, tors...@lodderstedt.net wrote:
> 
> Hi all,
> 
> the report is correct. Please consider it an errata to RFC 6819.
> 
> kind regards,
> Torsten.
> 
> Am 08.12.2015 16:05, schrieb RFC Errata System:
>> The following errata report has been held for document update
>> for RFC6819, "OAuth 2.0 Threat Model and Security Considerations".
>> --
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=6819&eid=4267
>> --
>> Status: Held for Document Update
>> Type: Editorial
>> Reported by: David Gladstone 
>> Date Reported: 2015-02-09
>> Held by: Kathleen Moriarty (IESG)
>> Section: 4.4.1.11
>> Original Text
>> -
>> If an authorization server includes a nontrivial amount of entropy
>> Corrected Text
>> --
>> If an authorization server includes a trivial amount of entropy
>> Notes
>> -
>> The threat being described outlines a scenario where too little
>> entropy is involved; countermeasures include using non-trivial amounts
>> of entropy.
>> --
>> RFC6819 (draft-ietf-oauth-v2-threatmodel-08)
>> --
>> Title   : OAuth 2.0 Threat Model and Security Considerations
>> Publication Date: January 2013
>> Author(s)   : T. Lodderstedt, Ed., M. McGloin, P. Hunt
>> Category: INFORMATIONAL
>> Source  : Web Authorization Protocol
>> Area: Security
>> Stream  : IETF
>> Verifying Party : IESG

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Mix-Up About The Mix-Up Mitigation

[Phil Hunt (IDM)]

I am in agreement with Brian. 

I understand what Mike is trying to do is safer, but I too am concerned that 
the escalation in knowledge/skills for oauth clients is significant. 

This may not be the same concern as for OIDC where we can expect more 
sophistication. 

Phil

> On Jan 12, 2016, at 20:03, Justin Richer  wrote:
> 
> +1 to Brian’s point, and points to Mike for promising to address this. I 
> wasn’t able to attend the meeting in Darmstadt, but I’ve been following the 
> discussion and original papers. Let’s take this one piece at a time and not 
> overreach with a solution.
> 
> In particular, the whole “late binding discovery” bit would cause huge 
> problems on its own. There’s good reason that OpenID Connect mandates that 
> the “iss” value returned from the discovery endpoint MUST be the same as the 
> “iss” value coming back from the ID Token, so let’s not ignore that.
> 
>  — Justin
> 
>> On Jan 12, 2016, at 5:53 PM, Mike Jones  wrote:
>> 
>> John Bradley and I went over this today and I'm already planning on 
>> simplifying the draft along the lines described. I would have written this 
>> earlier but I've been busy at a NIST meeting today. 
>> 
>> John has also stated writing a note about how cut-and-paste does and doesn't 
>> apply here but hasn't finished it yet because he's been similarly occupied.  
>> He's also started writing up the state_hash token request parameter, as he 
>> agreed to do.
>> 
>> Watch this space for the new draft...
>> 
>> Best wishes,
>> -- Mike
>> From: Brian Campbell
>> Sent: ‎1/‎12/‎2016 5:24 PM
>> To: oauth
>> Subject: [OAUTH-WG] Mix-Up About The Mix-Up Mitigation
>> 
>> The "IdP Mix-Up" and "Malicious Endpoint" attacks (as well as variations on 
>> them) take advantage of the fact that there's nothing in the OAuth 
>> authorization response to the client's redirect_uri that identifies the 
>> authorization server. As a result, a variety of techniques can be used to 
>> trick the client into sending the code (or token in some cases) to the wrong 
>> endpoint.
>> 
>> To the best of my recollection the general consensus coming out of the 
>> meetings in Darmstadt (which Hannes mentioned in OAuth Security Advisory: 
>> Authorization Server Mix-Up) was to put forth an I-D as a simple extension 
>> to OAuth, which described how to return an issuer identifier for the 
>> authorization server and client identifier as authorization response 
>> parameters from the authorization endpoint. Doing so enables the client to 
>> know which AS the response came from and thus avoid sending the code to a 
>> different AS. Also, it doesn't introduce application/message level 
>> cryptography requirements on client implementations. 
>> 
>> The mitigation draft that was posted yesterday diverges considerably from 
>> that with a significantly expanded scope that introduces OpenID Connect ID 
>> Tokens (sort of anyway) to regular OAuth and the retrieval of a 
>> metadata/discovery document in-between the authorization request and the 
>> access token request. 
>> 
>> It is possible that my recollection from Darmstadt is wrong. But I expect 
>> others who were there could corroborate my account of what transpired. Of 
>> course, the agreements out of the Darmstadt meeting were never intended to 
>> be the final word - the whole WG would have the opportunity to weigh, as is 
>> now the case. However, a goal of meeting face-to-face was to come away with 
>> a good consensus towards a proposed solution that could (hopefully) be 
>> implementable in the very near term and move thought the IETF process in an 
>> expedited manner. I believe we'd reached consensus but the content of -00 
>> draft does not reflect it. 
>> 
>> I've made the plea off-list several times to simplify the draft to reflect 
>> the simple solution and now I'm doing the same on-list. Simplify the 
>> response validation to just say not to send the code/token back to an AS 
>> entity other that the one identified by the 'iss' in the response. And 
>> remove the id_token and JWT parts that . 
>> 
>> If this WG and/or the larger community believes that OAuth needs signed 
>> responses, let's develop a proper singed response mechanism. I don't know if 
>> it's needed or not but I do know that it's a decent chunk of work that 
>> should be conscientiously undertaken independent of what can and should be a 
>> simple to understand and implement fix for the idp mix-up problem.
>> 
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Rechartering OAuth: New Charter Text

[Phil Hunt (IDM)]

Hannes

I would like to propose a brief presentation on "events". While this might not 
end up being oauth wg activity, I think a lot of attendees may be interested. 

We might make this one of those if we have time topics. 

Phil

> On Jan 15, 2016, at 12:15, Hannes Tschofenig  
> wrote:
> 
> Hi Barry,
> 
> as discussed today I am forwarding you the new charter text for the
> OAuth working group.
> 
> In parallel to the IESG processing this re-chartering request we will
> run a call for adoption to also update the milestone list at the same time.
> 
> Ciao
> Hannes & Derek
> 
> --
> 
> Charter Text
> 
> The Web Authorization (OAuth) protocol allows a user to grant a
> third-party Web site or application access to the user's protected
> resources, without necessarily revealing their long-term credentials,
> or even their identity. For example, a photo-sharing site that
> supports OAuth could allow its users to use a third-party printing Web
> site to print their private pictures, without allowing the printing
> site to gain full control of the user's account and without having the
> user share his or her photo-sharing sites' long-term credential with
> the printing site.
> 
> The OAuth 2.0 protocol suite already includes
> 
> * a procedure for enabling a client to register with an authorization
> server,
> * a protocol for obtaining authorization tokens from an authorization
> server with the resource owner's consent, and
> * protocols for presenting these authorization tokens to protected
> resources for access to a resource.
> 
> This protocol suite has been enhanced with functionality for
> interworking with legacy identity infrastructure (e.g., SAML), token
> revocation, token exchange, dynamic client registration, token
> introspection, a standardized token format with the JSON Web Token, and
> specifications that mitigate security attacks, such as Proof Key for
> Code Exchange.
> 
> The ongoing standardization efforts within the OAuth working group
> focus on increasing interoperability of OAuth deployments and to
> improve security. More specifically, the working group is defining proof
> of possession tokens, developing a discovery mechanism, providing
> guidance for the use of OAuth with native apps, re-introducing
> the device flow used by devices with limited user interfaces, additional
> security enhancements for clients communicating with multiple service
> providers, definition of claims used with JSON Web Tokens, techniques to
> mitigate open redirector attacks, as well as guidance on encoding state
> information.
> 
> For feedback and discussion about our specifications please
> subscribe to our public mailing list at .
> 
> For security related bug reports that relate to our specifications
> please contact . If the reported
> bug report turns out to be implementation-specific we will attempt
> to forward it to the appropriate developers.
> 
> ___
> 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] IETF 95 - Buenos Aires

[Phil Hunt (IDM)]

+1. 

Phil

> On Jan 17, 2016, at 22:08, Anthony Nadalin  wrote:
> 
> I’m afraid that I would have to agree with Brian (hopefully this is not a 
> trend)
>  
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
> Sent: Friday, January 15, 2016 9:16 AM
> To: Hannes Tschofenig 
> Cc: oauth@ietf.org; Rolando Martínez 
> Subject: Re: [OAUTH-WG] IETF 95 - Buenos Aires
>  
> Speaking for myself but I suspect others might be in the same boat - I'd love 
> to see some additional time beyond the official meeting made available to try 
> and make more progress on the open work in OAuth. But the week before IETF in 
> a different country (even if it's only a 19h bus ride) just isn't 
> logistically feasible for me.
>  
> On Fri, Jan 15, 2016 at 7:11 AM, Hannes Tschofenig 
>  wrote:
> Would it make sense to add an OAuth day to the OpenID Summit to prepare
> the IETF meeting, to play around with code, etc?
> 
> On 01/15/2016 01:58 PM, John Bradley wrote:
> > Yes I am going.
> >
> > The University of Chile and RedHat are sponsoring a one day OpenID Summit 
> > on Mar 31.
> >
> > I will send the registration info to the list once we have it up.
> >
> > Anyone interested should email myself or Rolando who is cc’d on this.
> >
> > John B.
> >
> >> On Jan 15, 2016, at 6:08 AM, Hannes Tschofenig  
> >> wrote:
> >>
> >> Hi all,
> >>
> >> I have just requested a 2 hour meeting slot for the next IETF meeting in
> >> Buenos Aires.
> >>
> >> It would be good to know whether you are planning to attend the upcoming
> >> IETF meeting. Please drop me a private mail to tell me your plans.
> >>
> >> Ciao
> >> Hannes
> >>
> >> ___
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
>  
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

[Phil Hunt (IDM)]

+1 for adoption

+1 for Brian's comments

Phil

> On Jan 20, 2016, at 14:42, Brian Campbell  wrote:
> 
> I conditionally accept this document as a starting point for work in the 
> OAuth working group on the assumption that the considerable simplifications 
> discussed and accepted at 
> http://www.ietf.org/mail-archive/web/oauth/current/msg15351.html will be 
> incorporated.
> 
> This document is (should be) intended to provide a mitigation to a security 
> problem. As such, it would be nice to see it progress a little faster than 
> the typical WG document. The more quickly the document can progress and/or be 
> perceived as stable, the better.
> 
>> On Tue, Jan 19, 2016 at 4:49 AM, Hannes Tschofenig 
>>  wrote:
>> Hi all,
>> 
>> this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see
>> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00
>> 
>> Please let us know by Feb 9th whether you accept / object to the
>> adoption of this document as a starting point for work in the OAuth
>> working group.
>> 
>> Note: This call is related to the announcement made on the list earlier
>> this month, see
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html. More
>> time for analysis is provided due to the complexity of the topic.
>> 
>> Ciao
>> Hannes & Derek
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Phil Hunt (IDM)]

Right but OAuth is the layer that needs to relay the request to the authen 
service. 

+1 on adoption

However we need to discuss more on w this as a registry or how it is used in 
the overall architecture to pass signalling (hint maybe that falls to connect?) 

Phil

> On Jan 20, 2016, at 12:37, Justin Richer  wrote:
> 
> Just reiterating my stance that this document detailing user authentication 
> methods has no place in the OAuth working group.
> 
> — Justin
> 
>> On Jan 19, 2016, at 6:48 AM, Hannes Tschofenig  
>> wrote:
>> 
>> Hi all,
>> 
>> this is the call for adoption of Authentication Method Reference Values, see
>> https://tools.ietf.org/html/draft-jones-oauth-amr-values-03
>> 
>> Please let us know by Feb 2nd whether you accept / object to the
>> adoption of this document as a starting point for work in the OAuth
>> working group.
>> 
>> Note: The feedback during the Yokohama meeting was inconclusive, namely
>> 9 for / zero against / 6 persons need more information.
>> 
>> You feedback will therefore be important to find out whether we should
>> do this work in the OAuth working group.
>> 
>> Ciao
>> Hannes & Derek
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

[Phil Hunt (IDM)]

I recall making this point in Germany. 99% of existing use is fine. OIDC is 
probably the largest community that *might* have an issue. 

I recall proposing a new security document that covers oauth security for 
dynamic scenarios. "Dynamic" being broadly defined to mean:
* clients who have configured at runtime or install time (including clients 
that do discovery)
* clients that communicate with more than one endpoint
* clients that are deployed in large volume and may update frequently (more 
discussion of "public" cases)
* clients that are script based (loaded into browser on the fly)
* others?

Phil

> On Jan 25, 2016, at 10:39, George Fletcher  wrote:
> 
> would

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

[Phil Hunt (IDM)]

When the RP acting as the client issues a authorize redirect to the UA it has 
to make it with TLS

Phil

> On Jan 25, 2016, at 17:53, Nov Matake  wrote:
> 
> It doen't say anything about the first request which initiate the login flow.
> It is still a reasonable assumption that RP puts a "login with FB" button on 
> a non TLS-protected page.
> 
> nov
> 
>> On Jan 26, 2016, at 10:45, Phil Hunt  wrote:
>> 
>> I would find it hard to believe that is true.
>> 
>> From 6749 Sec 3.1 
>>Since requests to the authorization endpoint result in user
>>authentication and the transmission of clear-text credentials (in the
>>HTTP response), the authorization server MUST require the use of TLS
>>as described in Section 1.6 when sending requests to the
>>authorization endpoint.
>> 
>> Sec 3.1.2.1 
>>The redirection endpoint SHOULD require the use of TLS as described
>>in Section 1.6 when the requested response type is "code" or "token",
>>or when the redirection request will result in the transmission of
>>sensitive credentials over an open network.  This specification does
>>not mandate the use of TLS because at the time of this writing,
>>requiring clients to deploy TLS is a significant hurdle for many
>>client developers.  If TLS is not available, the authorization server
>>SHOULD warn the resource owner about the insecure endpoint prior to
>>redirection (e.g., display a message during the authorization
>>request).
>> 
>>Lack of transport-layer security can have a severe impact on the
>>security of the client and the protected resources it is authorized
>>to access.  The use of transport-layer security is particularly
>>critical when the authorization process is used as a form of
>>delegated end-user authentication by the client (e.g., third-party
>>sign-in service).
>> 
>> Section 10.5 talks about transmission of authorization codes in connection 
>> with redirects.
>> 
>> Also see 6819, Sec 4.4.1.1 regarding eavesdropping or leaking of authz codes.
>> 
>> 
>> Phil
>> 
>> @independentid
>> www.independentid.com
>> phil.h...@oracle.com
>> 
>> 
>> 
>> 
>> 
>>> On Jan 25, 2016, at 4:52 PM, nov matake  wrote:
>>> 
>>> The first assumption is coming from the original security report at 
>>> http://arxiv.org/abs/1601.01229.
>>> RFC 6749 requires TLS between RS and AS, and also between UA and AS, but 
>>> not between UA and RS.
>>> 
>>> The blog post is based on my Japanese post, and it describes multi-AS case.
>>> Nat's another post describes the case which can affect single-AS case too.
>>> http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/
>>> 
>>> nov
>>> 
>>>> On Jan 26, 2016, at 08:22, Phil Hunt  wrote:
>>>> 
>>>> Sorry, meant to reply-all.
>>>> 
>>>> Phil
>>>> 
>>>> @independentid
>>>> www.independentid.com
>>>> phil.h...@oracle.com
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> Begin forwarded message:
>>>>> 
>>>>> From: Phil Hunt 
>>>>> Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
>>>>> Date: January 25, 2016 at 3:20:19 PM PST
>>>>> To: Nat Sakimura 
>>>>> 
>>>>> I am having trouble with the very first assumption. The user-agent sets 
>>>>> up a non TLS protected connection to the RP? That’s a fundamental 
>>>>> violation of 6749.
>>>>> 
>>>>> Also, the second statement says the RP (assuming it acts as OAuth client) 
>>>>> is talking to two IDPs.  That’s still a multi-AS case is it not?
>>>>> 
>>>>> Phil
>>>>> 
>>>>> @independentid
>>>>> www.independentid.com
>>>>> phil.h...@oracle.com
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Jan 25, 2016, at 2:58 PM, Nat Sakimura  wrote:
>>>>>> 
>>>>>> Hi Phil, 
>>>>>> 
>>>>>> Since I was not in Darmstadt, I really do not know what was discussed 
>>>>>> there, but with the compromised developer documentation described in 
>>>

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

[Phil Hunt (IDM)]

Also the authz endpoint is required to force tls. So if the client doesn't do 
it the authz should reject (eg by upgrading to tls). 

Phil

> On Jan 25, 2016, at 19:29, Phil Hunt (IDM)  wrote:
> 
> When the RP acting as the client issues a authorize redirect to the UA it has 
> to make it with TLS
> 
> Phil
> 
>> On Jan 25, 2016, at 17:53, Nov Matake  wrote:
>> 
>> It doen't say anything about the first request which initiate the login flow.
>> It is still a reasonable assumption that RP puts a "login with FB" button on 
>> a non TLS-protected page.
>> 
>> nov
>> 
>>> On Jan 26, 2016, at 10:45, Phil Hunt  wrote:
>>> 
>>> I would find it hard to believe that is true.
>>> 
>>> From 6749 Sec 3.1 
>>>Since requests to the authorization endpoint result in user
>>>authentication and the transmission of clear-text credentials (in the
>>>HTTP response), the authorization server MUST require the use of TLS
>>>as described in Section 1.6 when sending requests to the
>>>authorization endpoint.
>>> 
>>> Sec 3.1.2.1 
>>>The redirection endpoint SHOULD require the use of TLS as described
>>>in Section 1.6 when the requested response type is "code" or "token",
>>>or when the redirection request will result in the transmission of
>>>sensitive credentials over an open network.  This specification does
>>>not mandate the use of TLS because at the time of this writing,
>>>requiring clients to deploy TLS is a significant hurdle for many
>>>client developers.  If TLS is not available, the authorization server
>>>SHOULD warn the resource owner about the insecure endpoint prior to
>>>redirection (e.g., display a message during the authorization
>>>request).
>>> 
>>>Lack of transport-layer security can have a severe impact on the
>>>security of the client and the protected resources it is authorized
>>>to access.  The use of transport-layer security is particularly
>>>critical when the authorization process is used as a form of
>>>delegated end-user authentication by the client (e.g., third-party
>>>sign-in service).
>>> 
>>> Section 10.5 talks about transmission of authorization codes in connection 
>>> with redirects.
>>> 
>>> Also see 6819, Sec 4.4.1.1 regarding eavesdropping or leaking of authz 
>>> codes.
>>> 
>>> 
>>> Phil
>>> 
>>> @independentid
>>> www.independentid.com
>>> phil.h...@oracle.com
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> On Jan 25, 2016, at 4:52 PM, nov matake  wrote:
>>>> 
>>>> The first assumption is coming from the original security report at 
>>>> http://arxiv.org/abs/1601.01229.
>>>> RFC 6749 requires TLS between RS and AS, and also between UA and AS, but 
>>>> not between UA and RS.
>>>> 
>>>> The blog post is based on my Japanese post, and it describes multi-AS case.
>>>> Nat's another post describes the case which can affect single-AS case too.
>>>> http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/
>>>> 
>>>> nov
>>>> 
>>>>> On Jan 26, 2016, at 08:22, Phil Hunt  wrote:
>>>>> 
>>>>> Sorry, meant to reply-all.
>>>>> 
>>>>> Phil
>>>>> 
>>>>> @independentid
>>>>> www.independentid.com
>>>>> phil.h...@oracle.com
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> Begin forwarded message:
>>>>>> 
>>>>>> From: Phil Hunt 
>>>>>> Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
>>>>>> Date: January 25, 2016 at 3:20:19 PM PST
>>>>>> To: Nat Sakimura 
>>>>>> 
>>>>>> I am having trouble with the very first assumption. The user-agent sets 
>>>>>> up a non TLS protected connection to the RP? That’s a fundamental 
>>>>>> violation of 6749.
>>>>>> 
>>>>>> Also, the second statement says the RP (assuming it acts as OAuth 
>>>>>> client) is talking to two IDPs.  That’s still a multi-AS case is it not?
>>>>>> 
>>>>>> Phil
>>>>>> 
>>

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

[Phil Hunt (IDM)]

Still don't see it. Though i think the diagram is wrong (the rp should redirct 
to the ua and not call the authz direct), the IDP should either return an error 
or redirect the RP to TLS. 

I don't see this as proper oauth protocol since the RP is MITM the UA rather 
than acting as a client. 

Phil

> On Jan 25, 2016, at 19:57, nov matake  wrote:
> 
> In this flow, AuthZ endpoint is forced to be TLS-protected.
> http://nat.sakimura.org/wp-content/uploads/2016/01/oauth-idp-mixup.png
> 
> However, RP’s redirect response which causes following AuthZ request is still 
> not TLS-protected, and modified on the attacker’s proxy.
> 
> Section 3.2 of this report also describes the same flow.
> http://arxiv.org/pdf/1601.01229v2.pdf
> 
>> On Jan 26, 2016, at 12:37, Phil Hunt (IDM)  wrote:
>> 
>> Also the authz endpoint is required to force tls. So if the client doesn't 
>> do it the authz should reject (eg by upgrading to tls). 
>> 
>> Phil
>> 
>>> On Jan 25, 2016, at 19:29, Phil Hunt (IDM)  wrote:
>>> 
>>> When the RP acting as the client issues a authorize redirect to the UA it 
>>> has to make it with TLS
>>> 
>>> Phil
>>> 
>>>> On Jan 25, 2016, at 17:53, Nov Matake  wrote:
>>>> 
>>>> It doen't say anything about the first request which initiate the login 
>>>> flow.
>>>> It is still a reasonable assumption that RP puts a "login with FB" button 
>>>> on a non TLS-protected page.
>>>> 
>>>> nov
>>>> 
>>>>> On Jan 26, 2016, at 10:45, Phil Hunt  wrote:
>>>>> 
>>>>> I would find it hard to believe that is true.
>>>>> 
>>>>> From 6749 Sec 3.1 
>>>>>Since requests to the authorization endpoint result in user
>>>>>authentication and the transmission of clear-text credentials (in the
>>>>>HTTP response), the authorization server MUST require the use of TLS
>>>>>as described in Section 1.6 when sending requests to the
>>>>>authorization endpoint.
>>>>> 
>>>>> Sec 3.1.2.1 
>>>>>The redirection endpoint SHOULD require the use of TLS as described
>>>>>in Section 1.6 when the requested response type is "code" or "token",
>>>>>or when the redirection request will result in the transmission of
>>>>>sensitive credentials over an open network.  This specification does
>>>>>not mandate the use of TLS because at the time of this writing,
>>>>>requiring clients to deploy TLS is a significant hurdle for many
>>>>>client developers.  If TLS is not available, the authorization server
>>>>>SHOULD warn the resource owner about the insecure endpoint prior to
>>>>>redirection (e.g., display a message during the authorization
>>>>>request).
>>>>> 
>>>>>Lack of transport-layer security can have a severe impact on the
>>>>>security of the client and the protected resources it is authorized
>>>>>to access.  The use of transport-layer security is particularly
>>>>>critical when the authorization process is used as a form of
>>>>>delegated end-user authentication by the client (e.g., third-party
>>>>>sign-in service).
>>>>> 
>>>>> Section 10.5 talks about transmission of authorization codes in 
>>>>> connection with redirects.
>>>>> 
>>>>> Also see 6819, Sec 4.4.1.1 regarding eavesdropping or leaking of authz 
>>>>> codes.
>>>>> 
>>>>> 
>>>>> Phil
>>>>> 
>>>>> @independentid
>>>>> www.independentid.com
>>>>> phil.h...@oracle.com
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Jan 25, 2016, at 4:52 PM, nov matake  wrote:
>>>>>> 
>>>>>> The first assumption is coming from the original security report at 
>>>>>> http://arxiv.org/abs/1601.01229.
>>>>>> RFC 6749 requires TLS between RS and AS, and also between UA and AS, but 
>>>>>> not between UA and RS.
>>>>>> 
>>>>>> The blog post is based on my Japanese post, and it describes multi-AS 
>>>>>> case.
>>>>>> Nat's another post describes the case which ca

Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft

[Phil Hunt (IDM)]

Agreed. 

The security ext draft might fit well with the general grab bag of issues 
around all the "dynamic" cases. 

It would be stronger than a new threat model ext draft which would likely be 
informational. 

Phil

> On Jan 26, 2016, at 12:10, Torsten Lodderstedt  
> wrote:
> 
> Hi Mike,
> 
> I really like the new revision since it is much simpler :-)
> 
> My comments:
> 
> I'm fine with describing all mitigations we talked about in Darmstadt in 
> one/this spec. But the state check at the tokens endpoint is supposed to be a 
> mitigation against code injection/cut and paste attack, which is not directly 
> related to IDP/AS mix up. So I would suggest to change the name of the spec, 
> probably "OAuth security extensions"?
> 
> I think the code injection/cut and paste attack should be described more 
> extensively in the introduction. It's important for the reader to understand, 
> why this mitigation is defined at all. Moreover, I think the description of 
> the mitigation is still incomplete/spread over the document. In order to 
> detect code injection, the RP not only needs to send the state to the tokens 
> endpoint, it also needs to (directly or indirectly) _bind_ the state to the 
> particular user agent (session). Otherwise, the attacker can inject the state 
> along with the solen code easily. I would suggest to merge
> 
>  "To prevent replay of the state in another browser instance by an 
> attacker, the state value MUST be tied to the browser instance in a way that 
> cannot be forged by an attacker. Section 4 of 
> [I‑D.bradley‑oauth‑jwt‑encoded‑state]
>  provides several examples of how a client can accomplish this."
> 
> into section 5.
> 
> I thought we had discussed to also give implementors a guideline on using 
> state to prevent CSRF as well? How will we take care of that topic? 
> 
> kinds regards,
> Torsten.
> 
> 
>> Am 21.01.2016 um 07:28 schrieb Mike Jones:
>> John Bradley and I collaborated to create   the second OAuth 2.0 
>> Mix-Up Mitigation draft.  Changes were:
>> ·   Simplified by no longer specifying the signed JWT method for 
>> returning the mitigation information.
>> ·   Simplified by no longer depending upon publication of a discovery 
>> metadata document.
>> ·   Added the “state” token request parameter.
>> ·   Added examples.
>> ·   Added John Bradley as an editor.
>>  
>> The specification is available at:
>> ·   http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01
>>  
>> An HTML-formatted version is also available at:
>> ·   
>> http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-01.html
>>  
>>   -- Mike
>>  
>> P.S.  This note was also posted at http://self-issued.info/?p=1526 and as 
>> @selfissued.
>>  
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

[Phil Hunt (IDM)]

We discussed that redirecr helps but we wanted the Token endpoint to also be 
able to detect assuming many client devs won't implement the check. 

Phil

> On Jan 28, 2016, at 20:54, Nat Sakimura  wrote:
> 
> My preferred way of dealing with mix-up has been to use separate redirection 
> URI but your using issuer instead is for the backward compatibility? 
> 
> Nat
> 
> 2016年1月29日(金) 2:53 John Bradley :
>> Yes,  I note either mitigation in draft-jones-oauth-mix-up-mitigation-01 
>> will stop this attack.
>> 
>> White listing AS seems tempting, but is just sweeping the problem partially 
>> under the rug.  
>> There are probably good policy reasons to whitelist AS but we shouldn’t let 
>> this AS mixup be one of them.
>> 
>> John B.
>> 
>> 
>>> On Jan 27, 2016, at 10:42 PM, Nat Sakimura  wrote:
>>> 
>> 
>>> I see. That's like double cut-n-paste. 
>>> 
>>> I tried to capture this case of used-to-be-good AS turning Compromised AS 
>>> (Log leaking AS) in a sequence diagram: http://j.mp/1QtDeKD
>>> 
>>> Given this, just relying on not using random AS is not good enough. You 
>>> would probably require AS w/ISMS with the policy of not logging un-masked 
>>> credentials and has strict access control on the log ;-) 
>>> 
>>> Nat
>>> 
>>> 2016年1月28日(木) 9:38 Hans Zandbelt :
 indeed, if the attacker is able to phish the user, he can put up a
 script that first triggers the authorization request to the compromised
 AS (i.e. the AS at which he has access to the logs and gathers the state
 value from) through the Client, and subsequently trigger the redirect to
 the good AS using an auto-refresh of that same phishing page (with the
 stolen state value); no need to control the authorization endpoint of
 the compromised AS itself
 
 Hans.
>> 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>> 
>>> https://www.ietf.org/mailman/listinfo/oauth
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [Ace] Questions about OAuth and DTLS

[Phil Hunt (IDM)]

There is a more general problem in PaaS deployment about how RA and AS 
infrastructure discover and coordinate with each other. For the most part this 
hasn't been necessary since usually the AS and RS are controlled by the same 
admins. But in PaaS/IaaS the requirements vary widely. 

How does an RS indicate to an AS what tokens it is able to support (directly or 
indirectly via a security module). And then subsequently for the as and rs to 
let the client know?

We need to broaden discovery to cover all the scenarios so that automated and 
secure config of AS/RS/Tkn/Reg/RS entities works. 

Phil

> On Feb 8, 2016, at 07:04, John Bradley  wrote:
> 
> The RS is going to have to advertise what presentment mechanisms it supports.
> 
> We don’t have that yet.   I suspect that it might be part of OAuth Discovery. 
>  Currently that mostly cover AS discovery, but for the RS I could see doing a 
> head on the resource and getting back a link to a JSON document that would 
> contain meta-data about the RS.
> 
> The standard OAuth answer to this question is the client would get it from 
> the service documentation, but that is not really scalable.
> 
> 
>> On Feb 5, 2016, at 5:30 AM, Ludwig Seitz  wrote:
>> 
>> On 02/04/2016 05:14 PM, John Bradley wrote:
>>> In https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution
>>> 
>>> The proof key is included in the access token or provided out of band.
>>> 
>>> The proof mechanism to the RS is what would determine if the key type needs 
>>> to match DTLS .
>>> If the proof is DTLS then they would need to match.
>> 
>> Thank you John, this leads me to another question (maybe I just missed it in 
>> the PoP drafts): Who decides what the proof mechanism should be? How is the 
>> proof mechanism signaled to the client (the client may support several proof 
>> mechanisms)?
>> 
>> /Ludwig
>> 
>> 
>> -- 
>> Ludwig Seitz, PhD
>> SICS Swedish ICT AB
>> Ideon Science Park
>> Building Beta 2
>> Scheelevägen 17
>> SE-223 70 Lund
>> 
>> Phone +46(0)70 349 9251
>> http://www.sics.se
> 
> ___
> 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] Initial OAuth working group Discovery specification

[Phil Hunt (IDM)]

Another example is to look at scim discovery(in contrast with connect).

When asked separately the answers may be different. 

Asking what is the oauth server for scim is yet another relation.  So may be we 
need a scheme for oauth where query is rs:someval and optionally an acnt value 
to. 

For example
Get ./well-known/webfinger?rel=oauth&query=rs:scim&acnt:ph...@example.com

Note i probably have the compound query syntax wrong. 

Phil

> On Feb 9, 2016, at 14:03, John Bradley  wrote:
> 
> If we keep webfinger I don’t think that having a generic OAuth rel makes 
> sense.   It should be up to each API/Protocol to define it’s own rel value 
> like Connect has done.
> 
> It is not reasonable to think that a persons ID provider is going to be the 
> same as the one for calendaring or photo sharing.
> 
> So I could go two ways with webfinger,  leave it out completely, or leave it 
> in but make it up to the application to define a rel value.
> I expect that some things using UMA in web-finger would point directly to the 
> resource and the resource would point the client at the correct UMA server.
> 
> The config file name in .well-known could stay as openid-configuration for 
> historical reasons or we could change it.
> 
> I think we first need to decide if every protocol/API is going to have its 
> own config file, we are going to get apps to retrieve multiple files,  or 
> everything is going to go into one config-file and applicatins just add to 
> that?
> 
> I prefer not to change the file name if we are going for one config file, but 
> if we do one alias/link is probably not the end of the world, as I doubt 
> people will ever remove openid-configuration one if they have it now.
> 
> John B.
> 
>  
>> On Feb 9, 2016, at 2:19 PM, Justin Richer  wrote:
>> 
>> Mike, thanks for putting this up.
>> 
>> 
>> I would like to propose for two changes that have been brought up before:
>> 
>> 1) The wholesale removal of section 2, Webfinger lookup. 
>> 
>> 2) The changing of "/.well-known/openid-configuration” to 
>> "/.well-known/oauth-authorization-server” or something else not 
>> openid-related.
>> 
>> 
>> 
>>  — Justin
>> 
>> 
>>> On Feb 9, 2016, at 9:09 AM, Mike Jones  wrote:
>>> 
>>> We have created the initial working group version of OAuth Discovery based 
>>> on draft-jones-oauth-discovery-01, with no normative changes.
>>>  
>>> The specification is available at:
>>> ·   http://tools.ietf.org/html/draft-ietf-oauth-discovery-00
>>>  
>>> An HTML-formatted version is also available at:
>>> ·   http://self-issued.info/docs/draft-ietf-oauth-discovery-00.html
>>>  
>>>   -- Mike
>>>  
>>> P.S.  This notice was also posted at http://self-issued.info/?p=1534 and as 
>>> @selfissued.
>>>  
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Initial OAuth working group Discovery specification

[Phil Hunt (IDM)]

The rel for scim returns the endpoint for scim. 

The rel for oauth returns endpoints for oauth. 

The query lets the client say i want the endpoint for oauth used for scim. 

I suppose you could reverse it but then we'll have oauth discovery happening in 
different ways across many different specs. One set of considerations is 
enough. :-)

Phil

> On Feb 9, 2016, at 14:52, John Bradley  wrote:
> 
> You would define a rel uri for SCIM.   The SCIM entry can have sub properties 
> if it supported more than one auth type,  or you could have a SCIM discovery 
> document that the URI points to.
> 
> There are probably multiple ways to do it.
> 
> I don’t think trying to have a oauth rel and then sub types is going to make 
> sense to developers.  It is also not a good fit for Webfinger.
> 
> I also suspect that SCIM is more naturally part of a authentication service 
> It may be that the authentication service points at the SCIM service.
> 
> Remember that webfinger is a account alias and may not be the subject that 
> the SP/RP knows the user as.
> 
> Each service will need to be thought through for webfinger as the account 
> identity may mean different things depending on the protocol, and not every 
> protocol needs per user discovery.
> 
> John B
>> On Feb 9, 2016, at 7:39 PM, Phil Hunt (IDM)  wrote:
>> 
>> Another example is to look at scim discovery(in contrast with connect).
>> 
>> When asked separately the answers may be different. 
>> 
>> Asking what is the oauth server for scim is yet another relation.  So may be 
>> we need a scheme for oauth where query is rs:someval and optionally an acnt 
>> value to. 
>> 
>> For example
>> Get ./well-known/webfinger?rel=oauth&query=rs:scim&acnt:ph...@example.com
>> 
>> Note i probably have the compound query syntax wrong. 
>> 
>> Phil
>> 
>>> On Feb 9, 2016, at 14:03, John Bradley  wrote:
>>> 
>>> If we keep webfinger I don’t think that having a generic OAuth rel makes 
>>> sense.   It should be up to each API/Protocol to define it’s own rel value 
>>> like Connect has done.
>>> 
>>> It is not reasonable to think that a persons ID provider is going to be the 
>>> same as the one for calendaring or photo sharing.
>>> 
>>> So I could go two ways with webfinger,  leave it out completely, or leave 
>>> it in but make it up to the application to define a rel value.
>>> I expect that some things using UMA in web-finger would point directly to 
>>> the resource and the resource would point the client at the correct UMA 
>>> server.
>>> 
>>> The config file name in .well-known could stay as openid-configuration for 
>>> historical reasons or we could change it.
>>> 
>>> I think we first need to decide if every protocol/API is going to have its 
>>> own config file, we are going to get apps to retrieve multiple files,  or 
>>> everything is going to go into one config-file and applicatins just add to 
>>> that?
>>> 
>>> I prefer not to change the file name if we are going for one config file, 
>>> but if we do one alias/link is probably not the end of the world, as I 
>>> doubt people will ever remove openid-configuration one if they have it now.
>>> 
>>> John B.
>>> 
>>>  
>>>> On Feb 9, 2016, at 2:19 PM, Justin Richer  wrote:
>>>> 
>>>> Mike, thanks for putting this up.
>>>> 
>>>> 
>>>> I would like to propose for two changes that have been brought up before:
>>>> 
>>>> 1) The wholesale removal of section 2, Webfinger lookup. 
>>>> 
>>>> 2) The changing of "/.well-known/openid-configuration” to 
>>>> "/.well-known/oauth-authorization-server” or something else not 
>>>> openid-related.
>>>> 
>>>> 
>>>> 
>>>>  — Justin
>>>> 
>>>> 
>>>>> On Feb 9, 2016, at 9:09 AM, Mike Jones  
>>>>> wrote:
>>>>> 
>>>>> We have created the initial working group version of OAuth Discovery 
>>>>> based on draft-jones-oauth-discovery-01, with no normative changes.
>>>>>  
>>>>> The specification is available at:
>>>>> ·   http://tools.ietf.org/html/draft-ietf-oauth-discovery-00
>>>>>  
>>>>> An HTML-formatted version is also available at:
>>>>> ·   http://self-issued.info/docs/draft-ietf-oauth-discovery-00.html
>>>>>  
>>>>>   -- Mike
>>>>>  
>>>>> P.S.  This notice was also posted at http://self-issued.info/?p=1534 and 
>>>>> as @selfissued.
>>>>>  
>>>>> ___
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> 
>>>> ___
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
> 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Phil Hunt (IDM)]

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 believe that more folks in the group 
> will support the document.
>  
> Ciao
> Hannes & Derek
>  
>  
>  
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing lis

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

[Phil Hunt (IDM)]

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:
> >> 
> >> 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 [mail

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

[Phil Hunt (IDM)]

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

[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 
>>>>  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] OAuth Discovery spec pared down to its essence

[Phil Hunt (IDM)]

How does the client request the oauth configuration assigned to xyz?

The example you give appears to presume a single oauth infrastructure for all 
apps. 

The only way right now to have apps specific oauth is to infer the relation by 
the domain "xyz.example.com".  

That makes discovery more complex because there arw many more discovery 
locations and many more configurations to maintain. 

If example.com had separate oauth servers for services xyz and abc, how would 
discovery work from a single /.well-know endpoint?

Phil

> On Feb 18, 2016, at 09:41, Mike Jones  wrote:
> 
> Let me second John’s point that OAuth configuration information and 
> application configuration information need not be interspersed.  For 
> instance, if the service is at https://example.com and the XYZ application is 
> being used, then these configuration metadata documents could both be used:
> ·   https://example.com/.well-known/openid-configuration - OAuth 
> configuration metadata
> ·   https://example.com/.well-known/xyz-configuration - XYZ configuration 
> metadata
>  
> There’s not much point in defining a new /.well-known/oauth2.0 value, since 
> there is no such thing as generic OAuth 2.0.  By definition, it must always 
> be used in an application context that profiles OAuth 2.0 to enable 
> interoperability.  The existing /.well-known/openid-configuration value works 
> fine for this purpose.  Yes, the optics of having a different value might 
> seem better but it comes at the cost of interoperability problems.  In my 
> view, interop trumps optics.
>  
> To a point that George Fletcher made, WebFinger could still be used to learn 
> the locations of these configuration metadata documents if that makes sense 
> in the application context.  The editors took WebFinger out of the OAuth 
> Discovery document since it isn’t always applicable.
>  
>   Cheers,
>   -- Mike
>  
> From: John Bradley [mailto:ve7...@ve7jtb.com] 
> Sent: Thursday, February 18, 2016 7:41 AM
> To: Phil Hunt 
> Cc: Mike Jones ; oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence
>  
> I suspect that the configuration well-knowns are going to be on the root 
> domain.   You could try and get a user to put in crm.example.com, but I 
> suspect that is not going to work.
>  
> If the app doesn’t have a specific protocol identifier then it would use the 
> default.  
>  
> I don’t know if you can get around having some sort of app/protocol 
> identifier configured in the app.
>  
> John B.
>  
>  
>  
>  
>  
>  
> On Feb 18, 2016, at 9:49 AM, Phil Hunt  wrote:
>  
> resource service X could be any http accessible service:
>  
> * CRM
> * Finance
> * Payroll
> * ERP
> * any application on the web.
>  
> The spec seems to suggest that we use /.well-known/crm to discover OAuth 
> config for crm.  But that may cause conflict if crm has its own discovery. 
> Which leads us down the path of doing something like “crm-oauth”.
>  
> Then there is confusion about what host the discovery is done on.
>  
> For example, hypothetically do I do:
>  
> GET /.well-known/crm
> Host: example.com
>  
> But what about the CRM’s configuration information. Is this stomping on it?
>  
> Or, what If we put the oauth configuration at the host for the crm service:
> GET /.well-known/openid-configuration
> Host: crm.example.com
>  
> I think the point is that there is a relationship between a protected 
> resource and its designated OAuth service. 
>  
> The client needs to discover:
> * Where is its designated resource service and what security does it use
> * If it is OAuth, where is the intended OAuth configuration for that resource 
> service instance?
>  
> Phil
>  
> @independentid
> www.independentid.com
> phil.h...@oracle.com
>  
>  
>  
> 
>  
> On Feb 18, 2016, at 7:19 AM, John Bradley  wrote:
>  
> Can you clarify what you mean by “resource service x”?
>  
> Is that the RS base URI for the resource,  a specific URI that the client is 
> requesting?
>  
> That is getting UMA ish. 
>  
> The concept of a base RS URI is a rat hole that I prefer not to go down, as 
> it is something everyone thinks exists but like SCIM if it exists it is 
> protocol or deployment specific.
>  
> The notion that you would send the URI you are planning on requesting to a 
> Webfinger server to find the OAuth server, is probably going to have privacy 
> issues.
>  
> I suspect that you need to hand back a error from the resource to say where 
> the AS is, or have a .well-known for the RS.
>  
> RS discovery probably wants to be separate from AS discovery.  (Yes I do 
> think we need something,  UMA rpt or something like it might be a way to go)
>  
> John B.
>  
> On Feb 18, 2016, at 9:06 AM, Phil Hunt  wrote:
>  
> Maybe SCIM was a bad example.  It functions as a RESTful resource in the 
> context of OAuth.
>  
> I find the use of OIDC t

Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

[Phil Hunt (IDM)]

No. Much simpler. 

A service provider has decided to have a separate oauth server for each web 
'property'. This could be because they were acquired separately and run 
different infrastructures. Or the business structure keeps each BU completely 
separate. 

The client can't really depend on previously known or hard coded endpoints 
because there are 1000s of instances deployed (eg as in tenancies). 

This dynamic discovery is going to be particularly true of open source software 
that customers choose to host on PaaS cloud providers of their choosing. 

Phil

> On Feb 18, 2016, at 19:04, Nat Sakimura  wrote:
> 
> Hi Phil,
>  
> You wrote:
> > If example.com had separate oauth servers for services xyz and abc,
> > how would discovery work from a single /.well-known endpoint?
>  
> I am trying to understand your use case, but I am not sure if I do.
>  
> The use case seems to be such that:
>  
> -There is a client C1. It could be a CRM or any kind of application 
> that uses RFC6749 and RFC6750 to access other resources a resource server R1. 
> C1 and R1 has a pre-configured relationship.
> -The resource server R1 supports RFC6750, and can have multiple OAuth 
> RFC6749 endpoints that it supports, which are A1, …, An.
> -Ax supports multiple resource services, Rx.
> -There is a user U1 that wants to access C1, which in turn access R1. 
> U1 gets authenticated somehow at C1. It could be either through a password 
> system at C1, or through a federated login protocol supported at Ax, such as 
> OpenID Connect.
>  
> Another possibility is a case where Cx = Rx, which makes things a bit simpler.
>  
> Is this what you have in mind? Please let me know. If it is not, please 
> correct me.
>  
> Cheers,
>  
> Nat
> --
> PLEASE READ :This e-mail is confidential and intended for the
> named recipient only. If you are not an intended recipient,
> please notify the sender  and delete this e-mail.
>  
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt (IDM)
> Sent: Friday, February 19, 2016 2:09 AM
> To: Mike Jones
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence
>  
> How does the client request the oauth configuration assigned to xyz?
>  
> The example you give appears to presume a single oauth infrastructure for all 
> apps. 
>  
> The only way right now to have apps specific oauth is to infer the relation 
> by the domain "xyz.example.com".  
>  
> That makes discovery more complex because there arw many more discovery 
> locations and many more configurations to maintain. 
>  
> If example.com had separate oauth servers for services xyz and abc, how would 
> discovery work from a single /.well-know endpoint?
> 
> Phil
> 
> On Feb 18, 2016, at 09:41, Mike Jones  wrote:
> 
> Let me second John’s point that OAuth configuration information and 
> application configuration information need not be interspersed.  For 
> instance, if the service is at https://example.com and the XYZ application is 
> being used, then these configuration metadata documents could both be used:
> ·   https://example.com/.well-known/openid-configuration - OAuth 
> configuration metadata
> ·   https://example.com/.well-known/xyz-configuration - XYZ configuration 
> metadata
>  
> There’s not much point in defining a new /.well-known/oauth2.0 value, since 
> there is no such thing as generic OAuth 2.0.  By definition, it must always 
> be used in an application context that profiles OAuth 2.0 to enable 
> interoperability.  The existing /.well-known/openid-configuration value works 
> fine for this purpose.  Yes, the optics of having a different value might 
> seem better but it comes at the cost of interoperability problems.  In my 
> view, interop trumps optics.
>  
> To a point that George Fletcher made, WebFinger could still be used to learn 
> the locations of these configuration metadata documents if that makes sense 
> in the application context.  The editors took WebFinger out of the OAuth 
> Discovery document since it isn’t always applicable.
>  
>   Cheers,
>   -- Mike
>  
> From: John Bradley [mailto:ve7...@ve7jtb.com] 
> Sent: Thursday, February 18, 2016 7:41 AM
> To: Phil Hunt 
> Cc: Mike Jones ; oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence
>  
> I suspect that the configuration well-knowns are going to be on the root 
> domain.   You could try and get a user to put in crm.example.com, but I 
> suspect that is not going to work.
>  
> If the app doesn’t have

Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

[Phil Hunt (IDM)]

Inline...

Phil

> On Feb 18, 2016, at 22:19, Nat Sakimura  wrote:
> 
> Thanks for the explanation. Let me re-formulate.
>  
> Assumption

> 1. There are resource server – authorization server pairs: R1A1 … RnAn.
> 2. There are clients C1 … Cm.
> 3. These instances can be hosted on a multi-tenancy environment.
>  
> Flow
Step 0. The client discovers the resource server endpoint and its configs. 
Question: should that include oauth?? John seems to imply yes. 
> 1. Client Cx goes to a resource server Ry, but he was denied of the 
> access and was told to get an access token. Now Cx needs to know where to go.
> 2. Cx uses << Discovery>> to find the OAuth endpoints and the associated 
> metadata on Ay that corresponds to Ry.
Where is the discovery for Ay?
> 3. Cx goes and fetches the Discovery file.
> 4. Cx goes to Ay to get authorized using the config info in the Discovery 
> file and the rest is normal RFC6749.

Referring to the risk that a client discovered from a bad source (eg to insert 
a fake token endpoint), how does Ay know what discovery the client used was 
correct?  This might not be a problem in reality but it needs to work. 
>  
> Is this correct?
>  
> Nat
>  
> --
> PLEASE READ :This e-mail is confidential and intended for the
> named recipient only. If you are not an intended recipient,
> please notify the sender  and delete this e-mail.
>  
> From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com] 
> Sent: Friday, February 19, 2016 1:58 PM
> To: Nat Sakimura
> Cc: Mike Jones; oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence
>  
> No. Much simpler. 
>  
> A service provider has decided to have a separate oauth server for each web 
> 'property'. This could be because they were acquired separately and run 
> different infrastructures. Or the business structure keeps each BU completely 
> separate. 
>  
> The client can't really depend on previously known or hard coded endpoints 
> because there are 1000s of instances deployed (eg as in tenancies). 
>  
> This dynamic discovery is going to be particularly true of open source 
> software that customers choose to host on PaaS cloud providers of their 
> choosing. 
> 
> Phil
> 
> On Feb 18, 2016, at 19:04, Nat Sakimura  wrote:
> 
> Hi Phil,
>  
> You wrote:
> > If example.com had separate oauth servers for services xyz and abc,
> > how would discovery work from a single /.well-known endpoint?
>  
> I am trying to understand your use case, but I am not sure if I do.
>  
> The use case seems to be such that:
>  
> -   There is a client C1. It could be a CRM or any kind of application 
> that uses RFC6749 and RFC6750 to access other resources a resource server R1. 
> C1 and R1 has a pre-configured relationship.
> -   The resource server R1 supports RFC6750, and can have multiple OAuth 
> RFC6749 endpoints that it supports, which are A1, …, An.
> -   Ax supports multiple resource services, Rx.
> -   There is a user U1 that wants to access C1, which in turn access R1. 
> U1 gets authenticated somehow at C1. It could be either through a password 
> system at C1, or through a federated login protocol supported at Ax, such as 
> OpenID Connect.
>  
> Another possibility is a case where Cx = Rx, which makes things a bit simpler.
>  
> Is this what you have in mind? Please let me know. If it is not, please 
> correct me.
>  
> Cheers,
>  
> Nat
> --
> PLEASE READ :This e-mail is confidential and intended for the
> named recipient only. If you are not an intended recipient,
> please notify the sender  and delete this e-mail.
>  
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt (IDM)
> Sent: Friday, February 19, 2016 2:09 AM
> To: Mike Jones
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence
>  
> How does the client request the oauth configuration assigned to xyz?
>  
> The example you give appears to presume a single oauth infrastructure for all 
> apps. 
>  
> The only way right now to have apps specific oauth is to infer the relation 
> by the domain "xyz.example.com".  
>  
> That makes discovery more complex because there arw many more discovery 
> locations and many more configurations to maintain. 
>  
> If example.com had separate oauth servers for services xyz and abc, how would 
> discovery work from a single /.well-know endpoint?
> 
> Phil
> 
> On Feb 18, 2016, at 09:41, Mike Jones  wrote:
> 
> Let me second John’s point that OAuth configuration information and 
> application configuration information need not be interspersed.  For 
>

Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption

[Phil Hunt (IDM)]

Option A

Phil

> On Feb 19, 2016, at 13:39, Hans Zandbelt  wrote:
> 
> Option A: I agree with Mike that the complexity and implementation cost of 
> Option B will make adoption harder, which was also a concern with the first 
> iteration of Option A.
> 
> To be honest, I'm not sure most people would even understand why the 
> complexity would be required and just forget about it. At least with the 
> simplicity of the most recent option A they don't have to care, just add some 
> simple parameters/checks.
> 
> And for the record: I've also implemented option A in the mod_auth_openidc 
> [1] and lua-resty-openidc [2] clients for Apache and NGINX respectively.
> 
> Hans.
> 
> [1] https://github.com/pingidentity/mod_auth_openidc
> [2] https://github.com/pingidentity/lua-resty-openidc
> 
>> On 2/19/16 9:18 PM, Mike Jones wrote:
>> Option A.  I have higher confidence that this specification solves the
>> problems because it was designed during a 4-day security meeting
>> dedicated to this task by a group of over 20 OAuth security experts,
>> *including both sets of researchers in Germany who originally identified
>> the problem*.  This solution has also been implemented and interop
>> tested by Roland Hedberg, Brian Campbell, and I believe others.  Note
>> that the reason I am advocating this specification is **not** because
>> I'm an editor of it; my role was to record in spec language what the
>> OAuth security experts designed together over the 4-day period in Darmstadt.
>> 
>> I’ll also note that even if Option B also solves the problem, it comes
>> at significant adoption costs and complexity not found in A.  In
>> particular, it requires that developers understand support a new “Link
>> Relation” syntax not used elsewhere in OAuth.  As Nat writes about his
>> own draft in
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15789.html - there
>> is not a standard JSON syntax for link relations.  He writes “we could
>> easily create a parallel to it”.  I’d rather we solve the problem using
>> standard mechanisms already employed in OAuth, rather than risk
>> bifurcating OAuth in the developer community by unnecessarily
>> inventing/creating new syntax that is unfamiliar to developers and that
>> many of them may reject using.
>> 
>>   -- Mike
>> 
>> P.S.  Information about the OAuth security meeting can be found at
>> https://docs.google.com/document/d/136Cz2iwUFMdoKWZPCqZRhkmfmHAlJ6kM5OyeXzGptU4/edit
>> and
>> https://docs.google.com/document/d/1cRa11EgimnTeJZR1-PUpNRpi_u_EoSpO5NtakVbA_sk/edit
>> .
>> 
>> -Original Message-
>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
>> Sent: Friday, February 19, 2016 11:43 AM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for
>> Adoption
>> 
>> Early February I posted a mail to the list to make progress on the
>> solution to the OAuth Authorization Server Mix-Up problem discovered
>> late last year.
>> 
>> Here is my mail about the Authorization Server Mix-Up:
>> 
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html
>> 
>> Here is my mail to the list that tries to summarize the discussion
>> status and asked a few questions:
>> 
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15697.html
>> 
>> Unfortunately, my mail didn't lead to the intended success. While there
>> was some feedback I wasn't getting the desired response.
>> 
>> In order to move forward I believe we need a working group document that
>> serves as a starting point for further work in the group*. We have two
>> documents that provide similar functionality in an attempt to solve the
>> Authorization Server Mix-Up problem.
>> 
>> So, here is the question for the group. Which document do you want as a
>> starting point for work on this topic:
>> 
>> -- Option A: 'OAuth 2.0 Mix-Up Mitigation' by Mike Jones and John Bradley
>> 
>> Link:
>> 
>> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01
>> 
>> -- Option B: 'OAuth Response Metadata' by Nat Sakimura, Nov Matake and
>> Sascha Preibisch
>> 
>> Link:
>> 
>> https://tools.ietf.org/html/draft-sakimura-oauth-meta-07
>> 
>> Deadline for feedback is March, 4th.
>> 
>> Ciao
>> 
>> Hannes & Derek
>> 
>> PS: (*) Regardless of the selected solution we will provide proper
>> acknowledgement for those who contributed to the work.
>> 
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> -- 
> Hans Zandbelt  | Sr. Technical Architect
> hzandb...@pingidentity.com | Ping Identity
> 
> ___
> 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] OAuth 2.0 Discovery Location

[Phil Hunt (IDM)]

I am suggesting that part of the discovery solution has to be the client 
indicating what resource endpoint it wants the oauth configuration data for. 

So if res.example.evil.com is not a valid resource endpoint for as.example.com 
the authz discovery should fail in some way (eg return nothing). 

There may be better ways to do this. Eg combine discovery. Or change the order 
of discovery. 

One of OAuth's strength's and weaknesses is that the target of authorization 
(the resource) is never specified. It is often bound up in the client 
registration and an often implied 1:1 relationship between resource and as. 
Given that in discovery phase registration has not yet occurred it seems 
important that the client know it has a valid combination of endpoints etc. 

This is why I was disappointed about wglc on discovery. We had a starting point 
for group adoption but we haven't really defined the full requirements IMO. 

I am on vacation or I would put some thought into some draft changes or a new 
draft. I apologize I can't do it now. 

Phil

> On Feb 24, 2016, at 08:12, Nat Sakimura  wrote:
> 
> Hi Phil, 
> 
> Are you suggesting that the AS metadata should include the RS URIs? 
> Currently, it does not, but it can be done, I guess. 
> 
> The way oauth-meta works is that 
> 
> 1. RS tells the client where the AS is. 
> 2. AS tells the client which RS endpoints the token can be used. 
> 
> Even if there is a bad AS with a valid certs that proxies to the good RS, the 
> client will not send the token there as the authz server will say that is not 
> the place the client may want to send the token to. 
> 
> Nat
> 
> 2016年2月24日(水) 23:59 Phil Hunt :
>> Nat,
>> 
>> I’m not sure that having the resource server tell the client where its 
>> authorization server is secure by itself. The relationship between the 
>> Authorization Server and the Resource server need to be bound together in 
>> one of the discovery endpoints (the resource and/or the oauth service 
>> discovery).
>> 
>> If a client discovers a fake resource server that is proxying for a real 
>> resource server the current discovery spec will not lead the client to 
>> understand it has the wrong resource server. Rather the fake resource 
>> service will just have a fake discovery service. The hacker can now 
>> intercept resource payload as well as tokens because they were able to 
>> convince the client to use the legit authorization service but use the token 
>> against the hackers proxy.
>> 
>> The OAuth Discovery service needs to confirm to the client that the server 
>> is able to issue tokens for a stated resource endpoint.
>> 
>> This not only works in normal OAuth but should add security even to UMA 
>> situations.
>> 
>> Phil
>> 
>> @independentid
>> www.independentid.com
>> phil.h...@oracle.com
>> 
>> 
>> 
>> 
>> 
>>> On Feb 24, 2016, at 3:54 AM, Nat Sakimura  wrote:
>>> 
>>> 
>>> Hi Thomas, 
>>> 
>>> inline: 
>>> 
>>> 2016年2月22日(月) 18:44 Thomas Broyer :
 Couldn't the document only describe the metadata?
 I quite like the idea of draft-sakimura-oauth-meta if you really want to 
 do discovery, and leave it open to implementers / to other specs to define 
 a .well-known URL for "auto-configuration".
 The metadata described here would then either be used as-is, at any URL, 
 returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis 
 for other metadata specs (like OpenID Connect). 
 With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of 
 WWW-Authenticate response header, you have everything you need to proceed 
>>> 
>>> Yup. That's one of the requirements to be RESTful, is it not?  
>>> 
>>> In OAuth's case, the resource and the authorization server are usually 
>>> tightly coupled. (Otherwise, you need another specs like UMA.) 
>>> So, the resource server should be able to tell either the location of the 
>>> authz endpoint. In some trusted environment, the resource may as well 
>>> return the location of the authz server configuration data. In these cases, 
>>> you do not have to decide on what .well-known uri as you say. This frees up 
>>> developers from configuration file location collisions etc. We should 
>>> strive not to pollute the uri space as much as possible. 
>>>  
 (well, except if there are several ASs each with different scopes; sounds 
 like an edge-case to me though; maybe RFC6750 should instead be updated 
 with such a parameter such that an RS could return several 
 WWW-Authenticate: Bearer, each with its own "scope" and "duri" value?)
>>> 
>>> Yeah, I guess it is an edge case. I would rather like to see these authz 
>>> servers to develop a trust framework under which they can agree on a single 
>>> set of common scope parameter values. 
>>> 
>>> Cheers, 
>>> 
>>> Nat
>>> 
 
 
> On Fri, Feb 19, 2016 at 10:59 PM Justin Richer  wrote:
> The newly-trimmed OAuth Discovery document is helpful and moving in the 
> right direction.

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Phil Hunt (IDM)]

Mike

Publishing on dev pages does not work for software (esp open source) that is 
deployed both in enterprises and on PaaS cloud providers. 

The current draft is may codify current OIDC practice and be appropriate for 
oidc but it is not ready for generic oauth. There is no generic oauth 
experience at this time. 

Phil

> On Feb 24, 2016, at 10:25, Anthony Nadalin  wrote:
> 
> Sure there is, it is as you have now made it far easier and the security 
> considerations does not even address this
>  
> From: Mike Jones 
> Sent: Wednesday, February 24, 2016 10:22 AM
> To: Anthony Nadalin 
> Cc:  
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> As we’d discussed in person, there’s no effective security difference between 
> discovery information being published in an ad-hoc fashion on developer pages 
> and it being published in a standard format.  “Security by obscurity” adds no 
> real security at all.
>  
>   -- Mike
>  
> From: Anthony Nadalin 
> Sent: Wednesday, February 24, 2016 10:01 AM
> To: Mike Jones ; Phil Hunt (IDM) 
> ; Nat Sakimura 
> Cc:  
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> > The point of the WGLC is to finish standardizing the core discovery 
> > functionality that’s already widely deployed.
>  
> That may be widely deployed for OIDC but not widely deployed for OAuth. There 
> are some authentication mechanism discovery for endpoint that really should 
> not be in an OAuth standard since it’s really not dealt with. Now that all 
> this information is available it makes poking around the endpoint more 
> focused for people that want to disrupt your endpoints, that is really not 
> addressed in the security considerations section at all
>  
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
> Sent: Wednesday, February 24, 2016 9:54 AM
> To: Phil Hunt (IDM) ; Nat Sakimura 
> Cc:  
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> The point of the WGLC is to finish standardizing the core discovery 
> functionality that’s already widely deployed.
>  
> None of Nat or John or I are suggesting that additional related functionality 
> won’t be created.  I’m sure it will be.  Some applications will use WebFinger 
> to locate the discovery metadata.  Some will possibly use link headers.  Some 
> will possibly use application-specific .well-known values.  I’m sure there’s 
> other things I haven’t even thought about.  All of these depend upon having a 
> discovery metadata document format and none of them change it – other than 
> possibly to register additional discovery metadata values.
>  
> So by all means, the working group should continue discussing inventing 
> possible new related mechanisms that make sense in some contexts.  At the 
> same time, we can finish standardizing the already widely deployed core 
> functionality that all of these mechanisms will need.
>  
>   -- Mike
>  
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt (IDM)
> Sent: Wednesday, February 24, 2016 8:39 AM
> To: Nat Sakimura 
> Cc:  
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> I am suggesting that part of the discovery solution has to be the client 
> indicating what resource endpoint it wants the oauth configuration data for. 
>  
> So if res.example.evil.com is not a valid resource endpoint for 
> as.example.com the authz discovery should fail in some way (eg return 
> nothing). 
>  
> There may be better ways to do this. Eg combine discovery. Or change the 
> order of discovery. 
>  
> One of OAuth's strength's and weaknesses is that the target of authorization 
> (the resource) is never specified. It is often bound up in the client 
> registration and an often implied 1:1 relationship between resource and as. 
> Given that in discovery phase registration has not yet occurred it seems 
> important that the client know it has a valid combination of endpoints etc. 
>  
> This is why I was disappointed about wglc on discovery. We had a starting 
> point for group adoption but we haven't really defined the full requirements 
> IMO. 
>  
> I am on vacation or I would put some thought into some draft changes or a new 
> draft. I apologize I can't do it now. 
> 
> Phil
> 
> On Feb 24, 2016, at 08:12, Nat Sakimura  wrote:
> 
> Hi Phil, 
>  
> Are you suggesting that the AS metadata should include the RS URIs? 
> Currently, it does not, but it can be done, I guess. 
>  
> The way oauth-meta works is that 
>  
> 1. RS tells the client where the AS is. 
> 2. AS tells the client which RS end

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Phil Hunt (IDM)]

Where is the profile endpoint (oidc's resource server) published? (For the non 
OIDC people on the list). 

Phil

> On Feb 24, 2016, at 13:09, Mike Jones  wrote:
> 
> To the extent that generic OAuth 2.0 needs to publish some of the same 
> information as OpenID Connect – which is built on generic OAuth 2.0 – it 
> makes sense to publish that information using exactly the same syntax, since 
> that syntax is already in widespread use.  That what this draft accomplishes.
>  
> There’s nothing Connect-specific about using metadata response values like:
>  
>"authorization_endpoint": "https://server.example.com/authorize";,
>"token_endpoint": "https://server.example.com/token";,
>"token_endpoint_auth_methods_supported": ["client_secret_basic", 
> "private_key_jwt"],
>"registration_endpoint": "https://server.example.com/register";,
>"response_types_supported":  ["code", "token"],
>"service_documentation": 
> "http://server.example.com/service_documentation.html";,
>  
> Is there a reason that you would like the syntax for any of these or the 
> other generally applicable OAuth 2.0 metadata values to be different?  I 
> don’t see any good reason for unnecessary differences to be introduced.
>  
> -- Mike
>  
> From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com] 
> Sent: Wednesday, February 24, 2016 12:45 PM
> To: Anthony Nadalin 
> Cc: Mike Jones ;  
> 
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> Mike
>  
> Publishing on dev pages does not work for software (esp open source) that is 
> deployed both in enterprises and on PaaS cloud providers. 
>  
> The current draft is may codify current OIDC practice and be appropriate for 
> oidc but it is not ready for generic oauth. There is no generic oauth 
> experience at this time. 
> 
> Phil
> 
> On Feb 24, 2016, at 10:25, Anthony Nadalin  wrote:
> 
> Sure there is, it is as you have now made it far easier and the security 
> considerations does not even address this
>  
> From: Mike Jones 
> Sent: Wednesday, February 24, 2016 10:22 AM
> To: Anthony Nadalin 
> Cc:  
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> As we’d discussed in person, there’s no effective security difference between 
> discovery information being published in an ad-hoc fashion on developer pages 
> and it being published in a standard format.  “Security by obscurity” adds no 
> real security at all.
>  
>   -- Mike
>  
> From: Anthony Nadalin 
> Sent: Wednesday, February 24, 2016 10:01 AM
> To: Mike Jones ; Phil Hunt (IDM) 
> ; Nat Sakimura 
> Cc:  
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> > The point of the WGLC is to finish standardizing the core discovery 
> > functionality that’s already widely deployed.
>  
> That may be widely deployed for OIDC but not widely deployed for OAuth. There 
> are some authentication mechanism discovery for endpoint that really should 
> not be in an OAuth standard since it’s really not dealt with. Now that all 
> this information is available it makes poking around the endpoint more 
> focused for people that want to disrupt your endpoints, that is really not 
> addressed in the security considerations section at all
>  
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
> Sent: Wednesday, February 24, 2016 9:54 AM
> To: Phil Hunt (IDM) ; Nat Sakimura 
> Cc:  
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> The point of the WGLC is to finish standardizing the core discovery 
> functionality that’s already widely deployed.
>  
> None of Nat or John or I are suggesting that additional related functionality 
> won’t be created.  I’m sure it will be.  Some applications will use WebFinger 
> to locate the discovery metadata.  Some will possibly use link headers.  Some 
> will possibly use application-specific .well-known values.  I’m sure there’s 
> other things I haven’t even thought about.  All of these depend upon having a 
> discovery metadata document format and none of them change it – other than 
> possibly to register additional discovery metadata values.
>  
> So by all means, the working group should continue discussing inventing 
> possible new related mechanisms that make sense in some contexts.  At the 
> same time, we can finish standardizing the already widely deployed core 
> functionality that all of these mechanisms will need.
>  
>

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Phil Hunt (IDM)]

Yup. And because there many relations the client mist be able to discover it. 
The client does not know if the res server is legit. 

The userinfo is always fix and so u dont need discovery. 

Phil

> On Feb 24, 2016, at 14:05, Mike Jones  wrote:
> 
> In OpenID Connect, there’s a resource server called the UserInfo Endpoint 
> that returns claims about the authenticated user as a JSON data structure.  
> Its location is published in OpenID Connect discovery metadata as the 
> “userinfo_endpoint” metadata value, which is defined at 
> http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata.
>  
> We didn’t include the UserInfo Endpoint in the generic OAuth discovery spec 
> since in OAuth, there are lots of possible relationships between 
> authorization servers  and resource servers and they needn’t be one-to-one, 
> as is being actively discussed by the working group.  For instance, see 
> George Fletcher’s recent contribution.
>  
> Thanks for the good discussion, Phil.
>  
>         -- Mike
>  
> From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com] 
> Sent: Wednesday, February 24, 2016 1:25 PM
> To: Mike Jones
> Cc: 
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> Where is the profile endpoint (oidc's resource server) published? (For the 
> non OIDC people on the list). 
> 
> Phil
> 
> On Feb 24, 2016, at 13:09, Mike Jones  wrote:
> 
> To the extent that generic OAuth 2.0 needs to publish some of the same 
> information as OpenID Connect – which is built on generic OAuth 2.0 – it 
> makes sense to publish that information using exactly the same syntax, since 
> that syntax is already in widespread use.  That what this draft accomplishes.
>  
> There’s nothing Connect-specific about using metadata response values like:
>  
>"authorization_endpoint": "https://server.example.com/authorize";,
>"token_endpoint": "https://server.example.com/token";,
>"token_endpoint_auth_methods_supported": ["client_secret_basic", 
> "private_key_jwt"],
>"registration_endpoint": "https://server.example.com/register";,
>"response_types_supported":  ["code", "token"],
>"service_documentation": 
> "http://server.example.com/service_documentation.html";,
>  
> Is there a reason that you would like the syntax for any of these or the 
> other generally applicable OAuth 2.0 metadata values to be different?  I 
> don’t see any good reason for unnecessary differences to be introduced.
>  
> -- Mike
>  
> From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com] 
> Sent: Wednesday, February 24, 2016 12:45 PM
> To: Anthony Nadalin 
> Cc: Mike Jones ;  
> 
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> Mike
>  
> Publishing on dev pages does not work for software (esp open source) that is 
> deployed both in enterprises and on PaaS cloud providers. 
>  
> The current draft is may codify current OIDC practice and be appropriate for 
> oidc but it is not ready for generic oauth. There is no generic oauth 
> experience at this time. 
> 
> Phil
> 
> On Feb 24, 2016, at 10:25, Anthony Nadalin  wrote:
> 
> Sure there is, it is as you have now made it far easier and the security 
> considerations does not even address this
>  
> From: Mike Jones 
> Sent: Wednesday, February 24, 2016 10:22 AM
> To: Anthony Nadalin 
> Cc:  
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> As we’d discussed in person, there’s no effective security difference between 
> discovery information being published in an ad-hoc fashion on developer pages 
> and it being published in a standard format.  “Security by obscurity” adds no 
> real security at all.
>  
>   -- Mike
>  
> From: Anthony Nadalin 
> Sent: Wednesday, February 24, 2016 10:01 AM
> To: Mike Jones ; Phil Hunt (IDM) 
> ; Nat Sakimura 
> Cc:  
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> > The point of the WGLC is to finish standardizing the core discovery 
> > functionality that’s already widely deployed.
>  
> That may be widely deployed for OIDC but not widely deployed for OAuth. There 
> are some authentication mechanism discovery for endpoint that really should 
> not be in an OAuth standard since it’s really not dealt with. Now that all 
> this information is available it makes poking around the endpoint more 
> focused for people that want to disrupt your endpoints, that is 

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Phil Hunt (IDM)]

Mike

Take a look at the assumptions you are making. 

You seem to be assuming application software dictates oauth infrastructure 
architecture by suggesting that apps register in iana.  

Would ms azure allow custom arch?

Phil

> On Feb 24, 2016, at 15:28, Mike Jones  wrote:
> 
> The UserInfo Endpoint path isn’t fixed and so has to be discovered.
>  
> I agree that for some OAuth profiles, one or more resource servers will have 
> to be discovered starting from the authorization server.  Working group 
> members have also described wanting to discover authorization servers 
> starting from resource servers.  There isn’t a standard practice for any of 
> this, which is why it’s intentionally left out of the current specification.
>  
> Once the IANA OAuth Discovery Metadata Registry has been established, which 
> will happen after the current specification has been approved, it will be 
> easy for subsequent specifications to document existing practice for 
> different OAuth profiles and register discovery metadata values supporting 
> them.  Some of those values will likely define ways to discover resource 
> servers, when applicable.
>  
> But first, we need to finish the existing spec, so that the registry enabling 
> these extensions gets established in the first place.
>  
>         -- Mike
>  
> From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com] 
> Sent: Wednesday, February 24, 2016 2:13 PM
> To: Mike Jones 
> Cc:  
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> Yup. And because there many relations the client mist be able to discover it. 
> The client does not know if the res server is legit. 
>  
> The userinfo is always fix and so u dont need discovery. 
> 
> Phil
> 
> On Feb 24, 2016, at 14:05, Mike Jones  wrote:
> 
> In OpenID Connect, there’s a resource server called the UserInfo Endpoint 
> that returns claims about the authenticated user as a JSON data structure.  
> Its location is published in OpenID Connect discovery metadata as the 
> “userinfo_endpoint” metadata value, which is defined at 
> http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata.
>  
> We didn’t include the UserInfo Endpoint in the generic OAuth discovery spec 
> since in OAuth, there are lots of possible relationships between 
> authorization servers and resource servers and they needn’t be one-to-one, as 
> is being actively discussed by the working group.  For instance, see George 
> Fletcher’s recent contribution.
>  
> Thanks for the good discussion, Phil.
>  
> -- Mike
>  
> From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com] 
> Sent: Wednesday, February 24, 2016 1:25 PM
> To: Mike Jones
> Cc: 
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> Where is the profile endpoint (oidc's resource server) published? (For the 
> non OIDC people on the list). 
> 
> Phil
> 
> On Feb 24, 2016, at 13:09, Mike Jones  wrote:
> 
> To the extent that generic OAuth 2.0 needs to publish some of the same 
> information as OpenID Connect – which is built on generic OAuth 2.0 – it 
> makes sense to publish that information using exactly the same syntax, since 
> that syntax is already in widespread use.  That what this draft accomplishes.
>  
> There’s nothing Connect-specific about using metadata response values like:
>  
>"authorization_endpoint": "https://server.example.com/authorize";,
>"token_endpoint": "https://server.example.com/token";,
>"token_endpoint_auth_methods_supported": ["client_secret_basic", 
> "private_key_jwt"],
>"registration_endpoint": "https://server.example.com/register";,
>"response_types_supported":  ["code", "token"],
>"service_documentation": 
> "http://server.example.com/service_documentation.html";,
>  
> Is there a reason that you would like the syntax for any of these or the 
> other generally applicable OAuth 2.0 metadata values to be different?  I 
> don’t see any good reason for unnecessary differences to be introduced.
>  
> -- Mike
>  
> From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com] 
> Sent: Wednesday, February 24, 2016 12:45 PM
> To: Anthony Nadalin 
> Cc: Mike Jones ;  
> 
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> Mike
>  
> Publishing on dev pages does not work for software (esp open source) that is 
> deployed both in enterprises and on PaaS cloud providers. 
>  
> The current

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Phil Hunt (IDM)]

And so does oracle and so does google. Each different. 

So how can an app dictate it then unless we all go to a common architecture?

Phil

> On Feb 24, 2016, at 16:04, Mike Jones  wrote:
> 
> Azure defines ways for resource servers to be registered for use with a 
> client and for clients to dynamically request an access token for use at a 
> particular resource server.  You can call that custom architecture if you 
> want.  It’s well-defined but it’s not currently in the standards realm.  I 
> know that Google has syntax for doing the same, as I’m sure do a lot of other 
> cloud OAuth deployments, such as Oracle’s.  For what it’s worth, the working 
> group talked about possibly producing a standard version of syntax for making 
> these kinds of requests during our discussions in Prague (during the Token 
> Exchange discussion) but nobody has run with this yet.
>  
> In this sense, yes, Azure is an application of the kind we’re talking about.  
> Azure already does define specific new OAuth 2.0 discovery metadata values 
> that are used in production.  A registry just doesn’t yet exist in which it 
> can register those that are of general applicability.
>  
>         -- Mike
>  
> From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com] 
> Sent: Wednesday, February 24, 2016 3:52 PM
> To: Mike Jones
> Cc: 
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> Mike
>  
> Take a look at the assumptions you are making. 
>  
> You seem to be assuming application software dictates oauth infrastructure 
> architecture by suggesting that apps register in iana.  
>  
> Would ms azure allow custom arch?
> 
> Phil
> 
> On Feb 24, 2016, at 15:28, Mike Jones  wrote:
> 
> The UserInfo Endpoint path isn’t fixed and so has to be discovered.
>  
> I agree that for some OAuth profiles, one or more resource servers will have 
> to be discovered starting from the authorization server.  Working group 
> members have also described wanting to discover authorization servers 
> starting from resource servers.  There isn’t a standard practice for any of 
> this, which is why it’s intentionally left out of the current specification.
>  
> Once the IANA OAuth Discovery Metadata Registry has been established, which 
> will happen after the current specification has been approved, it will be 
> easy for subsequent specifications to document existing practice for 
> different OAuth profiles and register discovery metadata values supporting 
> them.  Some of those values will likely define ways to discover resource 
> servers, when applicable.
>  
> But first, we need to finish the existing spec, so that the registry enabling 
> these extensions gets established in the first place.
>  
> -- Mike
>  
> From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com] 
> Sent: Wednesday, February 24, 2016 2:13 PM
> To: Mike Jones 
> Cc:  
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> Yup. And because there many relations the client mist be able to discover it. 
> The client does not know if the res server is legit. 
>  
> The userinfo is always fix and so u dont need discovery. 
> 
> Phil
> 
> On Feb 24, 2016, at 14:05, Mike Jones  wrote:
> 
> In OpenID Connect, there’s a resource server called the UserInfo Endpoint 
> that returns claims about the authenticated user as a JSON data structure.  
> Its location is published in OpenID Connect discovery metadata as the 
> “userinfo_endpoint” metadata value, which is defined at 
> http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata.
>  
> We didn’t include the UserInfo Endpoint in the generic OAuth discovery spec 
> since in OAuth, there are lots of possible relationships between 
> authorization servers and resource servers and they needn’t be one-to-one, as 
> is being actively discussed by the working group.  For instance, see George 
> Fletcher’s recent contribution.
>  
> Thanks for the good discussion, Phil.
>  
> -- Mike
>  
> From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com] 
> Sent: Wednesday, February 24, 2016 1:25 PM
> To: Mike Jones
> Cc: 
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> Where is the profile endpoint (oidc's resource server) published? (For the 
> non OIDC people on the list). 
> 
> Phil
> 
> On Feb 24, 2016, at 13:09, Mike Jones  wrote:
> 
> To the extent that generic OAuth 2.0 needs to publish some of the same 
> information as OpenID Connect – which is built on generic OAuth 2.0 – it 
> makes sense to publish th

Re: [OAUTH-WG] HTTP request signing and repeated query/header keys

[Phil Hunt (IDM)]

The issue for any service is that things like gateways and proxies may change 
or add parameters.

There is a long tradition with http to mess with things headers and payload in 
the real world. Not ideal, but a certain reality. 

Thus for certain services it is likely only possible to sign a subset of params 
that the client and service provider want to verify did not change. 

Phil

> On Feb 28, 2016, at 18:39, Manger, James  
> wrote:
> 
> Being able to selectively include or exclude individual query string 
> name=value parameters in a signature feels far too dangerous. Always sign 
> them all — with the only exception being the signature itself if transmitted 
> as a query string parameter.
> Unfortunately we do need to selectively include or exclude HTTP headers as 
> they are a mix of transport, app-layer, end-to-end, and hop-by-hop items.
>  
> Ignoring duplicate query parameter names is a poor design for a fairly 
> generic HTTP signing method. My suggestion would be to do a stable sort on 
> parameter names. That is, sort the names, but preserve the order of values 
> when a name appears multiple times. …hoping that works with almost all 
> frameworks.
>  
> --
> James Manger
>  
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brock Allen
> Sent: Monday, 29 February 2016 12:17 PM
> To: 'Justin Richer' 
> Cc: '' 
> Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header keys
>  
> Yea, I’m cool with just saying “duplicate keys won’t work” for my 
> implementation, unless I do some implementation specific thing like sort them 
> by value order or some such (but that would have to be on both sides).
>  
> -Brock
>  
> From: Justin Richer [mailto:jric...@mit.edu] 
> Sent: Sunday, February 28, 2016 8:13 PM
> To: Brock Allen 
> Cc:  
> Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header keys
>  
> Yeah, that’s the trick — you don’t want to end up replicating the entire HTTP 
> message inside the JWS envelope, because then you end up with a SOAP kind of 
> approach where you’re not really using the outside HTTP constructs to their 
> fullest anymore. 
>  
> In the end, I don’t think this spec is ever going to be perfectly universal, 
> but if it can hit a majority of use cases with a simple and robust solution, 
> I think we’re in good shape.
>  
>  — Justin
>  
> On Feb 28, 2016, at 1:50 PM, Brock Allen  wrote:
>  
> Now that I’m thinking about this, the only thing that comes to mind is a hash 
> of the value included somehow (which I’m sure you’ve already thought of). 
> That’s obviously more complexity and overhead for all scenarios to support 
> this edge case.
>  
> -Brock
>  
> From: Brock Allen [mailto:brockal...@gmail.com] 
> Sent: Sunday, February 28, 2016 4:40 PM
> To: 'Justin Richer' 
> Cc: '' 
> Subject: RE: [OAUTH-WG] HTTP request signing and repeated query/header keys
>  
> Ok, missed that – thanks.
>  
> For now in my implementation I’m also ignoring this problem :)
>  
> -Brock
>  
> From: Justin Richer [mailto:jric...@mit.edu] 
> Sent: Sunday, February 28, 2016 4:37 PM
> To: Brock Allen 
> Cc:  
> Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header keys
>  
> In §7.5 we currently have:
>  
>The behavior of repeated query parameters or repeated HTTP headers is
>undefined by this specification.  If a header or query parameter is
>repeated on either the outgoing request from the client or the
>incoming request to the protected resource, that query parameter or
>header name MUST NOT be covered by the hash and signature. [[ Note to
>the WG: is this something we need to cover? ]]
>  
> Which is to say: Yeah, that’s a problem, probably. We either declare this 
> behavior out of scope and say you can’t use this method with that kind of API 
> (or at least those parameters/headers) or we define a mechanism for handling 
> that. I’m in favor of the former, and removing the text from the generation 
> sections that says repeated parameters are processed with no special 
> handling, making them explicitly out of scope throughout.
>  
> I would love to see more feedback from the group about this, especially if 
> someone’s got a clever solution.
>  
>  — Justin
>  
> On Feb 28, 2016, at 1:31 PM, Brock Allen  wrote:
>  
> Given that the client can iterate over the query/headers in any order to 
> generate the concatenated value to hash, I think there’s an issue with query 
> string or header values with repeated keys. I’ll stick with query params for 
> simplicity in my sample.
>  
> If a client signs this concatenated query: “a=1&a=2” then the “p” value in 
> the signed JSON object could be this:
>  
> "p": [["a", "a"], "blah"]
>  
> On the resource server, how do you know which key/value pair to put in which 
> order for verification? Also, given that different server implementations 
> express these incoming parameters in different ways, it seems problematic to 
> be consistent.
>  
> Thanks.
>  
> -Brock
>  
>

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

[Phil Hunt (IDM)]

+1 for adoption. Again. 

Phil

> On Mar 2, 2016, at 17:03, William Denniss  wrote:
> 
> I support adoption of this specification by the working group.
> 
> We are already using some values in production and I see interoperability 
> advantages in having these standardized. 
> 
>> On Wed, Mar 2, 2016 at 4:42 PM Mike Jones  
>> wrote:
>> I support adoption of this specification by the working group.  Aspects of 
>> it are already being used in production by Google and Microsoft.  It is also 
>> normatively referenced by the mobile profile for OpenID Connect being 
>> produced by the OpenID MODRNA working group.
>> 
>> -- Mike
>> 
>> -Original Message-
>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
>> Sent: Thursday, February 18, 2016 5:09 AM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] 2nd Call for Adoption: Authentication Method Reference 
>> Values
>> 
>> In response to my message to the list regarding the initial call for 
>> adoption of the Authentication Method Reference Values draft, see 
>> https://www.ietf.org/mail-archive/web/oauth/current/msg15694.html, Mike 
>> submitted an updated version of the document to take raised concerns into 
>> account. Several working group participants responded positively to the new 
>> version.
>> 
>> We would therefore like to issue a 2nd call for adoption of the recently 
>> submitted version -05:
>> https://tools.ietf.org/html/draft-jones-oauth-amr-values-05
>> 
>> Please let us know by March 3rd whether you accept / object to the adoption 
>> of this document as a starting point for work in the OAuth working group.
>> 
>> Ciao
>> Hannes & Derek
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

[Phil Hunt (IDM)]

I strongly oppose. 2 major issues. 

This is not service discovery this is configuration lookup. The client must 
have already discovered the oauth issuer uri and the resource uri. 

The objective was to provide a method to ensure the client has a valid set of 
endpoints to prevent mitm of endpoints like the token endpoint to the resource 
server. 

The draft does not address the issue of a client being given a bad endpoint for 
an rs. What we end up with is a promiscuous authz service giving out tokens to 
an unwitting client. 

Phil

> On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov  wrote:
> 
> +1 to move forward with these
> 
>> On 10/03/16 17:35, Brian Campbell wrote:
>> +1
>> 
>> On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg 
>> wrote:
>> 
>>> I support this document being moved forward with these two changes:
>>> 
>>> - change name to “OAuth 2.0 Authorization Server Discovery Metadata” as
>>> proposed by Brian and
>>> - use the URI path suffix ’oauth-authorization-server’ instead of
>>> ’openid-configuration’ as proposed by Justin.
>>> 
 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig >>> :
 
 Hi all,
 
 This is a Last Call for comments on the  OAuth 2.0 Discovery
>>> specification:
 https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
 
 Since this document was only adopted recently we are running this last
 call for **3 weeks**.
 
 Please have your comments in no later than March 10th.
 
 Ciao
 Hannes & Derek
 
 ___
 OAuth mailing list
 OAuth@ietf.org
 https://www.ietf.org/mailman/listinfo/oauth
>>> — Roland
>>> 
>>> ”Everybody should be quiet near a little stream and listen."
>>> From ’Open House for Butterflies’ by Ruth Krauss
>>> 
>>> 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> 
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

[Phil Hunt (IDM)]

Nat,

Agree with your points. 

Regarding the last, I am not sure an AS should release the set of valid rs's. I 
think the returned data has to be limited somehow. Maybe by aud uri or maybe 
just a yes/no to a uri the client provides. This needs discussion. 

Am worried about the resource side discovery and how much we can intrude here. 
It may have similar issues disclosing approved ASs. 

Finally since we might not control rs discovery it may be possible that the 
discovery is fake. Maybe this is where something like software statements comes 
into play as it would at least prevent a mitm from changing the assertions in 
its discovery. It would not have the RS's private key and this signed 
statements might build trust.  

Phil

> On Mar 10, 2016, at 18:24, Nat Sakimura  wrote:
> 
> Phil, 
> 
> Right. So what my conditional approvals (11 conditions in total) said was to 
> drop the word "discovery" from everywhere. This is not a discovery spec. This 
> is a configuration lookup spec as you correctly points out. So, I am with you 
> here. 
> 
> Also, my 2nd conditiion is essentially saying to drop section 3. 
> 
> One thing that I overlooked and am with you is that we need to be able to 
> express the AS-RS relationships. I have been preaching this in the other 
> thread for so many times as you know so I thought I pointed it out, but 
> missed apparently in my previous comment. So, I would add my 12th condition: 
> 
> 12. A way to express a list of valid RSs for this AS needs to be added to 
> section 2. 
> 
> Best, 
> 
> Nat
> 
> 2016-03-11 2:09 GMT+09:00 Phil Hunt (IDM) :
>> I strongly oppose. 2 major issues. 
>> 
>> This is not service discovery this is configuration lookup. The client must 
>> have already discovered the oauth issuer uri and the resource uri. 
>> 
>> The objective was to provide a method to ensure the client has a valid set 
>> of endpoints to prevent mitm of endpoints like the token endpoint to the 
>> resource server. 
>> 
>> The draft does not address the issue of a client being given a bad endpoint 
>> for an rs. What we end up with is a promiscuous authz service giving out 
>> tokens to an unwitting client. 
>> 
>> Phil
>> 
>>> On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov  
>>> wrote:
>>> 
>>> +1 to move forward with these
>>> 
>>>> On 10/03/16 17:35, Brian Campbell wrote:
>>>> +1
>>>> 
>>>> On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg 
>>>> wrote:
>>>> 
>>>>> I support this document being moved forward with these two changes:
>>>>> 
>>>>> - change name to “OAuth 2.0 Authorization Server Discovery Metadata” as
>>>>> proposed by Brian and
>>>>> - use the URI path suffix ’oauth-authorization-server’ instead of
>>>>> ’openid-configuration’ as proposed by Justin.
>>>>> 
>>>>>> 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig >>>>> :
>>>>>> 
>>>>>> Hi all,
>>>>>> 
>>>>>> This is a Last Call for comments on the  OAuth 2.0 Discovery
>>>>> specification:
>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
>>>>>> 
>>>>>> Since this document was only adopted recently we are running this last
>>>>>> call for **3 weeks**.
>>>>>> 
>>>>>> Please have your comments in no later than March 10th.
>>>>>> 
>>>>>> Ciao
>>>>>> Hannes & Derek
>>>>>> 
>>>>>> ___
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>> — Roland
>>>>> 
>>>>> ”Everybody should be quiet near a little stream and listen."
>>>>> From ’Open House for Butterflies’ by Ruth Krauss
>>>>> 
>>>>> 
>>>>> ___
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> ___
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> 
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

[Phil Hunt (IDM)]

 
> 
> 4) Trying to add all the RS to the AS discovery document.  This seems 
> impractical as there would be multiple protocols and doesn’t address 
> un-configured RS.
> 
> 5) Some new AS endpoint that the client could introspect the RS URI and get 
> back metadata about if the client should send tokens there.
> A couple of problems with this.  The first is that it would not support 
> un-configured RS unless you add dst to the token and authorization endpoints. 
>   The other is that the introspection endpoint doesn’t have the context of 
> the RO and client_id unless you also pass the code/RT and client_id, and 
> probably client credentials.Basically this is trying to introspect the AT 
> to determine the audiance/dst.   By the time you build a new introspection 
> endpoint securely it is going to look like the token endpoint with a bit more 
> meta data about the token beyond expiry and scopes.
> 
> 
> I think we should go a head with the renamed "OAuth 2.0 Authorization Server 
> Discovery Metadata” 
> I am also fine with making the default document 'openid-configuration’  as 
> long as we allow for protocol specific variation so that SCIM2 could define a 
> file name.If people want we could do a API  to file name registry so that 
> protocol specific ones can be defined.
> 
> We are all-ready working on option 1 to secure AT, we need a spec like I 
> propose in 2 for bearer tokens.  We can add one request parameter and a bit 
> more token meta-data to the token response and that takes care of the 
> problem.   Honestly we probably should have separated scope and destination 
> in the first place and returned both dst and scope in the response all along, 
> so this is update that is consistent with the eisting architecture of OAuth 2.
> 
> Lets keep the two issues separate.
> 
> John B.
>  
> 
> 
> 
>> On Mar 11, 2016, at 12:07 AM, Anthony Nadalin  wrote:
>> 
>> The relationship between AS and RS need to be scoped to “does this RS accept 
>> tokens from this AS” as a list is too much information that could be used in 
>> the wrong way
>>  
>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura
>> Sent: Thursday, March 10, 2016 6:25 PM
>> To: Phil Hunt (IDM) 
>> Cc: oauth 
>> Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
>>  
>> Phil, 
>>  
>> Right. So what my conditional approvals (11 conditions in total) said was to 
>> drop the word "discovery" from everywhere. This is not a discovery spec. 
>> This is a configuration lookup spec as you correctly points out. So, I am 
>> with you here. 
>>  
>> Also, my 2nd conditiion is essentially saying to drop section 3. 
>>  
>> One thing that I overlooked and am with you is that we need to be able to 
>> express the AS-RS relationships. I have been preaching this in the other 
>> thread for so many times as you know so I thought I pointed it out, but 
>> missed apparently in my previous comment. So, I would add my 12th condition: 
>>  
>> 12. A way to express a list of valid RSs for this AS needs to be added to 
>> section 2. 
>>  
>> Best, 
>>  
>> Nat
>>  
>> 2016-03-11 2:09 GMT+09:00 Phil Hunt (IDM) :
>> I strongly oppose. 2 major issues. 
>>  
>> This is not service discovery this is configuration lookup. The client must 
>> have already discovered the oauth issuer uri and the resource uri. 
>>  
>> The objective was to provide a method to ensure the client has a valid set 
>> of endpoints to prevent mitm of endpoints like the token endpoint to the 
>> resource server. 
>>  
>> The draft does not address the issue of a client being given a bad endpoint 
>> for an rs. What we end up with is a promiscuous authz service giving out 
>> tokens to an unwitting client. 
>> 
>> Phil
>> 
>> On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov  
>> wrote:
>> 
>> +1 to move forward with these
>> 
>> On 10/03/16 17:35, Brian Campbell wrote:
>> +1
>>  
>> On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg 
>> wrote:
>>  
>> I support this document being moved forward with these two changes:
>>  
>> - change name to “OAuth 2.0 Authorization Server Discovery Metadata” as
>> proposed by Brian and
>> - use the URI path suffix ’oauth-authorization-server’ instead of
>> ’openid-configuration’ as proposed by Justin.
>>  
>> 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig > :
>>  
>> Hi all,
>>  
>> This is a Last Call for comments on the  OAuth 2.0 Discovery
>> specifi

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

[Phil Hunt (IDM)]

I will put that forward in an alternate draft. 

Phil

> On Mar 12, 2016, at 08:28, Mike Jones  wrote:
> 
> The AS metadata format is a necessary part of discovery.  No, it doesn’t 
> accomplish every possible aspect of discovery – nor was it ever intended to.  
> I’ve consistently encouraged Phil and others to write down additional aspects 
> of discovery in specifications that build upon this one so that the working 
> group and implementers can evaluate them.
>  
> Since we’re chartered to do discovery and this is part of discovery, no 
> rechartering is needed either for the current specification or for new 
> specifications performing additional discovery tasks.
>  
>   -- Mike
>  
> From: Anthony Nadalin 
> Sent: Saturday, March 12, 2016 8:20 AM
> To: Mike Jones ; Brian Campbell 
> ; John Bradley 
> Cc: oauth 
> Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
>  
> We agreed upon a discovery specification that the WG would work on, we did 
> not agree upon what this has turned out to actually be, so at the minimum the 
> chairs should call for adoption of a Authorization Server Metadata 
> specification and we can continue to work on a Discovery specification
>  
> From: Mike Jones 
> Sent: Saturday, March 12, 2016 8:06 AM
> To: Anthony Nadalin ; Brian Campbell 
> ; John Bradley 
> Cc: oauth 
> Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
>  
> The draft enables easy configuration of OAuth clients with an AS.  For 
> instance, the Microsoft “ADAL” OAuth client software uses AS metadata in this 
> format as an input at client configuration time.
>  
> As a side benefit, having this standard AS metadata format and returning the 
> issuer URL per the Mix-Up Mitigation draft will also enable clients to 
> validate that they are using a consistent set of AS endpoints and 
> information.  But even without the mitigation benefits, the client 
> configuration benefit is the primary reason for the specification.
>  
>   -- Mike
>  
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
> Sent: Friday, March 11, 2016 3:25 PM
> To: Brian Campbell ; John Bradley 
> 
> Cc: oauth 
> Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
>  
> Disagree, what purpose is this activity solving then, it was being pushed as 
> what was need to solve the Mix-up, but that is not true. So now you are 
> suggesting a change in scope and not dealing with discovery.
>  
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
> Sent: Friday, March 11, 2016 3:11 PM
> To: John Bradley 
> Cc: oauth 
> Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
>  
> I tend to agree with John that addressing the concerns Phil raises should be 
> part of (extension to) the core protocol.  And that those kinds of concerns 
> don't manifest in the way OAuth is typically deployed now. 
> 
> The hopefully soon to be named "OAuth 2.0 Authorization Server Metadata" 
> should keep it's scope to the publishing of authorization server metadata. 
> The act of doing discovery is beyond its scope and so is trying to prevent a 
> client from presenting a token to someplace it shouldn't.
> 
>  
> On Fri, Mar 11, 2016 at 9:08 AM, John Bradley  wrote:
> Inline
> On Mar 11, 2016, at 12:13 PM, Phil Hunt (IDM)  wrote:
>  
> John
>  
> In many case all the AS has to check is the domain name component to check 
> for mitm. 
>  
> POP and the other solns are dramatically more complex than a simple check. 
>  
> I was proposing ding that check at the authorization endpoint or token 
> endpoint as part of AT issuance. 
>  
> It is up to the AS how much of the path to validate and or put in the aud or 
> dst. 
>  
>  
>  
> I see it as part of the discovery(bad name aside) problem because we 
> discussed that if a client finds app.example.com how do we ensure it gets a 
> complete set of oauth endpoints as a valid set of endpoints--that a hacker 
> has not inserted one of their own endpoints. The most important endpoint to 
> get right is ensuring the resource server (and optionally the path) is the 
> correct one. We can't really define resource discovery but we can validate it 
> to some degree. 
>  
> I think it is part of core protocol security and should/must not require 
> discovery. 
>  
> What is app.example.com ? 
>  
> If it is the resource then the client would be preconfigured for it’s AS out 
> of band or optionally would do discovery on the issuer uri that you admit 
> needs

Re: [OAUTH-WG] Multiple authorization servers for one resource server

[Phil Hunt (IDM)]

A header might open another attack vector. Better to parse the jwt and look for 
the issuer assuming the jwt validates. 

Phil

> On Mar 12, 2016, at 09:02, Jim Willeke  wrote:
> 
> Why not register JWT as an access token type and then the the Issuer is 
> implied?
> 
> --
> -jim
> Jim Willeke
> 
>> On Sat, Mar 12, 2016 at 8:32 AM, Mike Schwartz  wrote:
>> Kawasaki-san,
>> 
>> This is a really good question: how to know the issuer of a bearer token. Is 
>> there a header that could be added to specify the issuer, or other important 
>> metadata?
>> 
>> - Mike
>> 
>> 
>> -
>> Michael Schwartz
>> Gluu
>> Founder / CEO
>> m...@gluu.org
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Multiple authorization servers for one resource server

[Phil Hunt (IDM)]

Right now we are discussing mis-configured clients that have been convinced to 
use a token or rs endpoint that has been mitm. Adding a new parameter increases 
attack surface because the rs is now ignoring the token abd believing the 
header which may have been inserted. 

Phil

> On Mar 12, 2016, at 11:29, Jim Willeke  wrote:
> 
> Would a header be a concern if TLS was used for transportation?
> 
> --
> -jim
> Jim Willeke
> 
>> On Sat, Mar 12, 2016 at 10:03 AM, Phil Hunt (IDM)  
>> wrote:
>> A header might open another attack vector. Better to parse the jwt and look 
>> for the issuer assuming the jwt validates. 
>> 
>> Phil
>> 
>>> On Mar 12, 2016, at 09:02, Jim Willeke  wrote:
>>> 
>>> Why not register JWT as an access token type and then the the Issuer is 
>>> implied?
>>> 
>>> --
>>> -jim
>>> Jim Willeke
>>> 
>>>> On Sat, Mar 12, 2016 at 8:32 AM, Mike Schwartz  wrote:
>>>> Kawasaki-san,
>>>> 
>>>> This is a really good question: how to know the issuer of a bearer token. 
>>>> Is there a header that could be added to specify the issuer, or other 
>>>> important metadata?
>>>> 
>>>> - Mike
>>>> 
>>>> 
>>>> -
>>>> Michael Schwartz
>>>> Gluu
>>>> Founder / CEO
>>>> m...@gluu.org
>>>> 
>>>> ___
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

[Phil Hunt (IDM)]

Inline

Phil

> On Mar 14, 2016, at 14:13, John Bradley  wrote:
> 
> We had two mandates.  One was to provide a spec for AS metadata.   The other 
> was to mitigate the client mixup attack.  The request was to do the latter 
> without requiring the former for clients that don’t otherwise need discovery.
There is no mandate for any of this. See 
http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt
> 
> Returning the issuer and client_id from the authorization endpoint and the 
> client checking them can be done by the client without discovery. 

How does this address the issue of whether the client is talking to the wrong 
endpoint?
> 
> Any client that has the resource and issuer hard coded probably doesn’t need 
> discovery.  
We agree


> One of the things that a client will need discovery for is to find the RS, so 
> requiring the client to know the RS URI before getting the AS config seems 
> backwards to me. 
How can you make an assumption on order? You seem to be conflating 
authentication with authorization by assuming the identity drives what the 
resource is. 

There are lots of applications that require user rights but are not identify 
centric. For example a document service. 
> 
> Unless the client tells the AS where it intends to use the token we will be 
> leaving a security hole because the bearer tokens will have too loose an 
> audience if they have one at all.
This is the biggest risk we have IMHO. 
> 
> True you are telling the AS (Webfinger service) what the RS is but that is 
> not at a place that is useful in the token production process.

This has nothing to do with token production. 

What we want to ensure is whether an honest client is correctly configured and 
has not been mislead - eg by a phishing page. 
> 
> I also think there are use cases where the AS doesn’t know all the possible 
> RS.   That is not something that a out of band check can address.

May be. Lets identify them. 

> There are also cases where a token might be good at multiple RS endpoints 
> intentionally.

>  In your solution the client would need to make a discovery request for each 
> endpoint.
Sure. Otherwise how would it know if there is one AS or a pool of AS servers 
assigned to each instance?
> Those requests lack the context of who the client and resource owner are.  I 
> think that will be a problem in some use cases. 

Not sure I agree. This is about discovering a valid set of endpoints. For mitm, 
we mainly want to check the hostname is correct. If a client chooses evil.com 
the cert can be valid and TLS will pass. How does it otherwise know it is 
supposed to talk to res.example.com?
> 
> If this is added to the token endpoint it would be checked when code or 
> refresh are exchanged, not every time the token is used.   
Your proposal requires rhe client to check. I am not clear how the AS can know 
the exact uri. It is far easier to validate than to lookup since as you say the 
client may be authorized to use multiple ASs. 
> With a out of band check the client would never know if a RS was 
> removed/revoked.  

Not sure that is in scope. 

None of the current proposals address this issue. 
>  
> 
> I don’t see checking when refreshing a token as something that is a huge 
> burden.

Still its a lot more than once. 

Why don't you draft another alternative?
> 
> If the server wants to do the check on it’s side then we could require the 
> client to send the RS URI in the token request. that way you really know the 
> client is not going to get a token for the wrong RS endpoint.
> If you check out of band in discovery you really have no idea if the client 
> is checking.

In the new webfinger draft, the client isn't checking. The service provider 
simply does not disclose oauth information to misconfigured clients. 
> 
> John B.
>  
> 
> 
>> On Mar 14, 2016, at 3:56 PM, Phil Hunt  wrote:
>> 
>> Thanks to Mike and John for their feedback.  I’ll take each in turn:
>> 
>> Mike,
>> 
>> Regarding your suggested amendments
>> 
>> Item 1: Returning the config URL would create two problems. One,it makes 
>> bound discovery a two-step process - that adds complexity.  It seems far 
>> simpler to mandate TLS (which I think it already does in the security 
>> considerations).  
>> 
>> The two-step process allows the current discovery process to continue. I 
>> disagree with this. This is why I put forward an “alternate" draft that is 
>> almost the same but simply adds the check before returning the configuration 
>> data.  I worry that  developers would have no incentive to do the two-step 
>> approach. They would just start at step 2 which in turn puts AS’s at risk of 
>> exposing tokens because it works. This makes OAuth promiscuous.
>> 
>> Regarding existing implementations. Most of those implementations are for 
>> OIDC.  I think it makes sense for OIDF to continue use of OIDC's discovery 
>> spec because the UserInfo endpoint is well defined and the likelihood of a 
>> client mis-inf

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

[Phil Hunt (IDM)]

ds of things that currently get folded into 
>>>>> “scope” that we might want to try separating out better: 
>>>>> 
>>>>> 
>>>>>   - What things do I want to access? (photos, profile) 
>>>>>   - What actions do I want to take on these things? (read, write, delete) 
>>>>>   - How long do I want these tokens to work? 
>>>>> (offline_access/refresh_token, one time use, next hour, etc) 
>>>>> 
>>>>> 
>>>>> I think the first one is close to the audience/resource parameters that 
>>>>> have been bandied about a few times, including in the current token 
>>>>> exchange document. We should be consistent across drafts in that regard. 
>>>>> The second is more traditional scope-ish. The third has been patched in 
>>>>> with things like “offline_access” in certain APIs. 
>>>>> 
>>>>> Just another vector to think about if we’re going to be adding things 
>>>>> like “audience” or “resource” or both to the token requests. 
>>>>> 
>>>>>   — Justin 
>>>>> 
>>>>> 
>>>>>> On Mar 14, 2016, at 6:26 PM, John Bradley >>>>> <mailto:ve7...@ve7jtb.com>> wrote: 
>>>>>> 
>>>>>> Yes I will work on another proposal for allowing clients to specify 
>>>>>> what resource they want a token for and providing the meta-data to the 
>>>>>> client about the resources that a token is valid for. 
>>>>>> 
>>>>>> We have part of it in the POP key distribution spec and talked about 
>>>>>> separating it, as it is used more places than just for assigning keys. 
>>>>>> I know some AS use different token formats for different RS so are 
>>>>>> all-ready needing to pass the resource in the request to avoid making 
>>>>>> a mess of scopes. 
>>>>>> 
>>>>>> John B. 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM) >>>>>> <mailto:phil.h...@oracle.com>> wrote: 
>>>>>>> 
>>>>>>> Inline 
>>>>>>> 
>>>>>>> Phil 
>>>>>>> 
>>>>>>> On Mar 14, 2016, at 14:13, John Bradley >>>>>> <mailto:ve7...@ve7jtb.com>> wrote: 
>>>>>>> 
>>>>>>>> We had two mandates.  One was to provide a spec for AS metadata. 
>>>>>>>> The other was to mitigate the client mixup attack.  The request was 
>>>>>>>> to do the latter without requiring the former for clients that don’t 
>>>>>>>> otherwise need discovery.
>>>>>>> There is no mandate for any of this. See 
>>>>>>> http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt
>>>>>>>  
>>>>>>>> 
>>>>>>>> Returning the issuer and client_id from the authorization endpoint 
>>>>>>>> and the client checking them can be done by the client without 
>>>>>>>> discovery.
>>>>>>> 
>>>>>>> How does this address the issue of whether the client is talking to 
>>>>>>> the wrong endpoint? 
>>>>>>>> 
>>>>>>>> Any client that has the resource and issuer hard coded probably 
>>>>>>>> doesn’t need discovery.
>>>>>>> We agree 
>>>>>>> 
>>>>>>> 
>>>>>>>> One of the things that a client will need discovery for is to find 
>>>>>>>> the RS, so requiring the client to know the RS URI before getting 
>>>>>>>> the AS config seems backwards to me.
>>>>>>> How can you make an assumption on order? You seem to be conflating 
>>>>>>> authentication with authorization by assuming the identity drives 
>>>>>>> what the resource is. 
>>>>>>> 
>>>>>>> There are lots of applications that require user rights but are not 
>>>>>>> identify centric. For example a document service. 
>>>>>>>> 
>>>>>>>> Unless the client tells the AS where it intends to use the

Re: [OAUTH-WG] Use cases for Audience Restricted tokens + AS and RS "discovery"

[Phil Hunt (IDM)]

There are two variations. 

Mitm the token endpoint is different then working one legit token endpoint 
against another thru redirect and state misdirection. 

In the mitm version you don't need multiple AS's.

Phil

> On Mar 18, 2016, at 15:04, Brian Campbell  wrote:
> 
> The "a. wrong AS /token endpoint" is the mix-up issue, which can be mitigated 
> by returning an identifier for the AS in the authorization response. It is 
> something that needs to be addressed but "discovery" or metadata aren't 
> needed and audience restricted access tokens tokens don't help.
> 
> Maybe that's obvious but there seems to be a lot of confusion on all this so 
> I wanted to reiterate it.
> 
>> On Thu, Mar 17, 2016 at 11:37 AM, George Fletcher  wrote:
>> Goals:
>> 
>> 1. Help the client not send a token to the "wrong" endpoint
>>a. wrong AS /token endpoint
>>b. evil RS endpoint(s)
>> 2. Allow good RS to determine if the token being validated was intended for 
>> that RS
>> 
>> Other high-level goals?
>> 
>> Use cases:
>> 
>> 1. RS that supports multiple AS (we've had this in production since 2011)
>> 2. RS rejects token not issued for use at the RS
>> 3. Client that dynamically supports new RS (say any client that supports the 
>> jabber API)
>> 4. Client that dynamically supports new AS
>> 
>> Feel free to add to the list :)
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

[Phil Hunt (IDM)]

gt;>>>>>>>>> metadata to the client needed? The AS can audience restrict the 
>>>>>>>>>> token as needed or respond with an error if it can't or wont issue a 
>>>>>>>>>> token for the resource the client asked for. 
>>>>>>>>>> 
>>>>>>>>>>> On Tue, Mar 15, 2016 at 9:37 AM, John Bradley  
>>>>>>>>>>> wrote:
>>>>>>>>>>> Yes,  I think bearer tokens with no audience are a bad idea.
>>>>>>>>>>> 
>>>>>>>>>>> The AS needs to infer an audience from the scopes snd/or have the 
>>>>>>>>>>> client specify the desired audience.
>>>>>>>>>>> 
>>>>>>>>>>> If the AT has a audience or audiences then as long as the endpoint 
>>>>>>>>>>> URI are provided as meta-data with the token, the   
>>>>>>>>>>> client can determine if it 
>>>>>>>>>>> is sending the token to the correct place.
>>>>>>>>>>> 
>>>>>>>>>>> I think Phil would prefer the server rather than the client do the 
>>>>>>>>>>> check, but the client   
>>>>>>>>>>> always needs to take some responsibility to not leak 
>>>>>>>>>>> tokens giving them to the wrong RS or the code to the wrong token 
>>>>>>>>>>> endpoint is leaking.
>>>>>>>>>>> 
>>>>>>>>>>> I imagine that claims based access tokens are going to become more 
>>>>>>>>>>> popular and the static relationship between one RS and one AS will 
>>>>>>>>>>> not be the majority of deployments over time. 
>>>>>>>>>>> 
>>>>>>>>>>> In any case where the client is configured up front to know the RS 
>>>>>>>>>>> and the AS it seems like that would not require Phil’s Solution, 
>>>>>>>>>>> but that is the only case supported by that discovery.
>>>>>>>>>>>   
>>>>>>>>>>> If the client itself is bad there is not much you can do to stop it 
>>>>>>>>>>> from passing on the AT in way way it wants.  That however is a 
>>>>>>>>>>> different problem and needs claimed URI or attestations to prevent 
>>>>>>>>>>> client spoofing.
>>>>>>>>>>> William and I are working on that in the mobile best practices 
>>>>>>>>>>> draft.
>>>>>>>>>>> 
>>>>>>>>>>> John B.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> On Mar 15, 2016, at 12:09 PM, George Fletcher  
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> I worry about two directions I see in this thread...
>>>>>>>>>>>> 
>>>>>>>>>>>> 1. Client's accessing resources dynamically so that discovery is 
>>>>>>>>>>>> required to know the correct AS, etc. This is pretty much the 
>>>>>>>>>>>> classic use case for UMA and I'd rather not re-invent the wheel.
>>>>>>>>>>>> 
>>>>>>>>>>>> 2. Creating a tight coupling between RS and AS such that RS 
>>>>>>>>>>>> endpoint changes must be continually communicated to the AS. If an 
>>>>>>>>>>>> RS supports multiple AS's then the RS has to deal with 
>>>>>>>>>>>> "guaranteed" delivery. The AS needs an endpoint to receive such 
>>>>>>>>>>>> communications. If not dynamic via APIs, then deployment of the 
>>>>>>>>>>>> new RS is bound by the associated AS's getting and deploying the 
>>>>>>>>>>>> new endpoints. Can both endpoints of the RS be supported within 
>>>>>>>>>>>&

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

[Phil Hunt (IDM)]

t;>>>>>>> 
>>>>>>>>>> If the client specifies the desired audience(s)/resource(s), is that 
>>>>>>>>>> metadata to the client needed? The AS can audience restrict the 
>>>>>>>>>> token as needed or respond with an error if it can't or wont issue a 
>>>>>>>>>> token for the resource the client asked for. 
>>>>>>>>>> 
>>>>>>>>>>> On Tue, Mar 15, 2016 at 9:37 AM, John Bradley  
>>>>>>>>>>> wrote:
>>>>>>>>>>> Yes,  I think bearer tokens with no audience are a bad idea.
>>>>>>>>>>> 
>>>>>>>>>>> The AS needs to infer an audience from the scopes snd/or have the 
>>>>>>>>>>> client specify the desired audience.
>>>>>>>>>>> 
>>>>>>>>>>> If the AT has a audience or audiences then as long as the endpoint 
>>>>>>>>>>> URI are provided as meta-data with the token, the   
>>>>>>>>>>> client can determine if it 
>>>>>>>>>>> is sending the token to the correct place.
>>>>>>>>>>> 
>>>>>>>>>>> I think Phil would prefer the server rather than the client do the 
>>>>>>>>>>> check, but the client   
>>>>>>>>>>> always needs to take some responsibility to not leak 
>>>>>>>>>>> tokens giving them to the wrong RS or the code to the wrong token 
>>>>>>>>>>> endpoint is leaking.
>>>>>>>>>>> 
>>>>>>>>>>> I imagine that claims based access tokens are going to become more 
>>>>>>>>>>> popular and the static relationship between one RS and one AS will 
>>>>>>>>>>> not be the majority of deployments over time. 
>>>>>>>>>>> 
>>>>>>>>>>> In any case where the client is configured up front to know the RS 
>>>>>>>>>>> and the AS it seems like that would not require Phil’s Solution, 
>>>>>>>>>>> but that is the only case supported by that discovery.
>>>>>>>>>>>   
>>>>>>>>>>> If the client itself is bad there is not much you can do to stop it 
>>>>>>>>>>> from passing on the AT in way way it wants.  That however is a 
>>>>>>>>>>> different problem and needs claimed URI or attestations to prevent 
>>>>>>>>>>> client spoofing.
>>>>>>>>>>> William and I are working on that in the mobile best practices 
>>>>>>>>>>> draft.
>>>>>>>>>>> 
>>>>>>>>>>> John B.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> On Mar 15, 2016, at 12:09 PM, George Fletcher  
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> I worry about two directions I see in this thread...
>>>>>>>>>>>> 
>>>>>>>>>>>> 1. Client's accessing resources dynamically so that discovery is 
>>>>>>>>>>>> required to know the correct AS, etc. This is pretty much the 
>>>>>>>>>>>> classic use case for UMA and I'd rather not re-invent the wheel.
>>>>>>>>>>>> 
>>>>>>>>>>>> 2. Creating a tight coupling between RS and AS such that RS 
>>>>>>>>>>>> endpoint changes must be continually communicated to the AS. If an 
>>>>>>>>>>>> RS supports multiple AS's then the RS has to deal with 
>>>>>>>>>>>> "guaranteed" delivery. The AS needs an endpoint to receive such 
>>>>>>>>>>>> communications. If not dynamic via APIs, then deployment of the 
>>>>>>>>>>>> new RS is bound by the associated A

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

[Phil Hunt (IDM)]

Nothing here has anything to do with mix-up. Thats another problem. 

Phil

> On Mar 16, 2016, at 16:50, John Bradley  wrote:
> 
> If you recall in Darmstadt, the group decided that the mix up attack needed 
> to be addressed without requiring discovery.
> 
> That is why I keep saying the are separate issues.
> 
> The proposed fix from the group for the AS confusion was to return a issuer 
> and client_id from the authorization endpoint, so that the client can check 
> the authorization response and determine if the response came from the same 
> AS that it made it’’s request to.
> 
> This is predicated on the precondition that the attacker can modify/proxy the 
> request , but not the response from the legitimate AS.
> 
> The client checks each response and compares the request issuer with the 
> response issuer.   It requires the client to be configured with a issuer for 
> each AS.
> 
> As a happy coincidence the issuer string is a HTTPS URI and could be used in 
> a discovery spec to get the meta-data for the AS.
> 
> I think that is confusing people into thinking that the IdP mixup mitigation 
> used discovery.  It doesn’t. 
> 
> You are the one who is requiring discovery in your proposal.
> 
> I should point out that your proposal requires a trusted and validated issuer 
> to be able to validate the RS.
> 
> If I were an attacker I could trick the client into registering with me I can 
> give it my bad issuer-x and  it would talk to my bad web-finger and validate 
> my bad RS at registration time.
> 
> On it’s own your discovery of the AS config and validation of the RS provides 
> no improved security.
> 
> The client would still need to do per request validation of the issuer and 
> client_id returned by the Authorization endpoint.
> 
> My proposal is to have the client send the RS URI to the AS and let it check 
> with each request as well and skip the requirement for discovery.
> 
> Your proposal doesn’t remove the per authorization request check.
> 
> John B.
> 
> 
>> On Mar 16, 2016, at 12:30 PM, Phil Hunt (IDM)  wrote:
>> 
>> John,
>> 
>> Mis configured token endpoint and resource endpoint is the same client 
>> misconfiguration issue where a client is mis-informed by mistake or 
>> mis-deed. 
>> 
>> Why do you propose to solve token endpoint in config discovery but feel 
>> resource endpoint must be reverified each time in the core protocol? 
>> 
>> Phil
>> 
>>> On Mar 16, 2016, at 07:46, John Bradley  wrote:
>>> 
>>> If the client sends the uri of the resource it intends to send the token to 
>>> in the token request the bad guy would get only a token audianced to itself 
>>> and not to good RS. 
>>> 
>>> You can't solve the problem of bearer tokens with multiple audiences 
>>> leaking.   That is a risk inherent in using that sort of token.   
>>> Compromise in one RS will impact all of them. 
>>> 
>>> The only safe way with bearer to deal with a RS the AS dosen't trust a RS 
>>> is to only have one audianced in the token. (or by introspection)
>>> 
>>> We have always known that and left it up to clients to make sure they are 
>>> secure by not sending tokens to bad RS. 
>>> 
>>> Now people want a AS check to prevent clients from being tricked if 
>>> developers are given bad info statically or dynamically.
>>> 
>>> What you are doing is safe as long as your developers don't make any 
>>> mistakes. 
>>> If you want to be safe and not have to preconfigure the AS you need to use 
>>> the refresh to get single audianced tokens, or PoP.
>>> 
>>> John B.
>>> 
>>>> On Mar 16, 2016 11:27 AM, "George Fletcher"  wrote:
>>>> 
>>>> 
>>>>> On 3/15/16 6:14 PM, John Bradley wrote:
>>>>> If the AS is audience restricting the tokens then it just needs to put 
>>>>> the right audience in the token based on what the client is asking for.  
>>>>> That is safe as the RS wouldn’t be able to replay the token someplace 
>>>>> else.
>>>> So let's assuming a client sends a token audience restricted to GoodRS 
>>>> instead to EvilRS. When EvilRS replays the token at the GoodRS endpoint, 
>>>> how does GoodRS reject the token because when GoodRS sends the token to 
>>>> the AS for introspection (or does so itself) the token will be audience 
>>>> restricted to the GoodRS and it will process the token. The only way to 
>>>> prevent this is with client-authen

Re: [OAUTH-WG] Resource Service metadata

[Phil Hunt (IDM)]

George

Very good question...

I considered that the RS metadata discovery could be fake. 

So the final step in configuration validation is to bind the relationship 
between as and rs discovery together to confirm the relationship is valid. 

We are of course assuming that a hacker needs to use the real AS authorize 
endpoint to succeed in obtaining an access token(it can't be mitm'd). Once the 
grant is obtained by the client, the threat comes when the client uses the 
grant at a mitm'd token endpoint OR an access token at a mitm'd resource 
endpoint. 

So the AS and its config set becomes the trust anchor. Binding allows us to 
extend trust to the RS discovery giving some assurance that a client has a 
correct set of endpoints including resource. 

John's solution requires translating aud to res url and changes to core oauth. 
He seems to imply there is a need for ongoing validation of resource. I'm not 
yet convinced that is really needed.  Maybe it is needed because the client 
could be convinced to follow a link embedded in a resource that is somehow not 
part of the defined audience?

Thanks

Phil

> On Mar 16, 2016, at 08:57, George Fletcher  wrote:
> 
> So, in thinking about all this AS restricting tokens to RS and "discovery" of 
> RS endpoints, etc. I wondered why we don't just leverage RS metadata like we 
> have AS metadata.
> 
> For an AS we require an 'iss' claim to use as an identifier of the AS. We 
> could do the same with RS metadata retrieving the metadata from a .well-known 
> location and including a claim of 'rsid' to use as an identifier of the 
> Resource Server.
> 
> This 'rsid' identifier could then be used for registration with the AS and 
> presentation by the client when requesting tokens.
> 
> This provides a separation between an identifier for a resource and the 
> specific endpoints the token will be sent to. A client could "discover" the 
> necessary endpoint on a periodic basis and use a single identifier with the 
> AS for any of the endpoints or scopes supported by the RS. If desired the RS 
> could expose the supported scopes in the RS metadata file.
> 
> Thoughts?
> 
> Thanks,
> George
> ___
> 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] Agenda Proposal

[Phil Hunt (IDM)]

Sounds good. 

Phil

> On Mar 21, 2016, at 15:18, Hannes Tschofenig  
> wrote:
> 
> Hi Phil,
> 
> we can put this topic as an additional agenda item to the list by
> removing time from the PoP and the mix-up agenda items
> 
> Ciao
> Hannes
> 
>> On 03/21/2016 09:46 PM, Phil Hunt wrote:
>> I’m not sure you intend to discuss it in the Mix-up section, but I think
>> we need time to discuss the correct configuration of clients and the
>> resource/aud relationship issues
>> (specifically: draft-campbell-oauth-resource-indicators
>>  
>> and draft-hunt-oauth-bound-config
>> ).
>> 
>> There is apparently overlap with mix-up mitigation (either in reality or
>> perception), so I think it is important to have a verbal discussion on
>> this to get to consensus and understanding of the separate issues.
>> 
>> As for POP-architecture, that has been on hold pending the mix-up
>> discussions and understanding of dynamic client risks.  So, not much
>> need to discuss from my perspective.
>> 
>> Thanks,
>> 
>> Phil
>> 
>> @independentid
>> www.independentid.com 
>> phil.h...@oracle.com 
>> 
>> 
>> 
>> 
>> 
>>> On Mar 21, 2016, at 1:15 PM, Hannes Tschofenig
>>> mailto:hannes.tschofe...@gmx.net>> wrote:
>>> 
>>> Hi all,
>>> 
>>> I need your help creating the agenda for the next meeting. We have a 2
>>> 1/2 hour slot and many different topics to discuss. I put a strawman
>>> proposal together but there are various things missing:
>>> 
>>> * who volunteers to present and to lead the discussion,
>>> * what time allocation is appropriate,
>>> * what you are trying to accomplish during the meeting (goals), and
>>> * what other items would you like to discuss (I know there are various
>>> items missing from the list).
>>> 
>>> So, you input is needed!
>>> 
>>> ---
>>> 
>>> IETF 95 OAuth Meeting Agenda
>>> Wednesday, 10:00-12:30
>>> Chairs: Hannes Tschofenig/Derek Atkins
>>> 
>>> - Status Update (Hannes, 5 min)
>>> 
>>> - OAuth 2.0 JWT Authorization Request (Nat, 15 min )
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
>>> 
>>> - OAuth 2.0 Mix-Up Mitigation (TBD, 45 min)
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-mix-up-mitigation/
>>> 
>>> - Proof-of-Possession (TBD, 35 min)
>>> http://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-possession/
>>> http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/
>>> http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-request/
>>> 
>>> - Token Exchange (TBD, 15 min)
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/
>>> 
>>> - OAuth 2.0 for Native Apps (William, 15 min)
>>> http://datatracker.ietf.org/doc/draft-wdenniss-oauth-native-apps/
>>> 
>>> - Authentication Method Reference Values (Mike, 15 min)
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
>>> 
>>> - Conclusion (Hannes, 5 min)
>>> 
>>> ---
>>> 
>>> The latest version can be found at:
>>> https://www.ietf.org/proceedings/95/agenda/agenda-95-oauth
>>> 
>>> Ciao
>>> Hannes & Derek
>>> 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [scim] Simple Federation Deployment

[Phil Hunt (IDM)]

Is the idp the center of all things for these users?

Usually you have a provisioning system that coordinates state and uses things 
like scim connectors to do this. 

Another approach from today would be to pass a scim event to the remote 
provider which then decides what needs to be done to facilitate the thingd you 
describe. 

Iow. Either the idp (sender) or the sp (receiver) have a provisioning system to 
do this. 

The solution and the simplicity depends on where the control needs to be. 

Phil

> On Apr 5, 2016, at 18:59, Hardt, Dick  wrote:
> 
> Use case: An admin for an organization would like to enable her users to 
> access a SaaS application at her IdP. 
> 
> User experience: 
> Admin authenticates to IdP in browser
> Admin selects SaaS app to federate with from list at IdP
> IdP optionally presents config options
> IdP redirects Admin to SaaS app
> Admin authenticates to SaaS app
> SaaS app optionally gathers config options
> SaaS app redirects admin to IdP
> IdP confirms successful federation => OIDC / SAML and SCIM are now configured 
> and working between IdP and SaaS App
> Who else is interested in solving this?
> 
> Is there interest in working on this in either SCIM or OAUTH Wgs?
> 
> Any one in BA interested in meeting on this topic this week?
> 
> — Dick
> ___
> scim mailing list
> s...@ietf.org
> https://www.ietf.org/mailman/listinfo/scim
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [scim] Simple Federation Deployment

[Phil Hunt (IDM)]

There may be some similar concerns on our side. Lets talk more this week. 

Phil

> On Apr 5, 2016, at 19:25, Hardt, Dick  wrote:
> 
> I’m talking about removing manual steps in what happens today where 
> configuring a SaaS app at an IdP (such as Google, Azure, Ping, Octa) requires 
> is a bunch of cutting and pasting of access tokens / keys / certs and doing a 
> bunch of  config that is error prone and unique for each relationship.
> 
> Don’t want to solve on the thread … looking to see if there is interest!
> 
> On 4/5/16, 7:11 PM, someone claiming to be "scim on behalf of Phil Hunt 
> (IDM)"  wrote:
> 
> Is the idp the center of all things for these users?
> 
> Usually you have a provisioning system that coordinates state and uses things 
> like scim connectors to do this. 
> 
> Another approach from today would be to pass a scim event to the remote 
> provider which then decides what needs to be done to facilitate the thingd 
> you describe. 
> 
> Iow. Either the idp (sender) or the sp (receiver) have a provisioning system 
> to do this. 
> 
> The solution and the simplicity depends on where the control needs to be. 
> 
> Phil
> 
> On Apr 5, 2016, at 18:59, Hardt, Dick  wrote:
> 
>> Use case: An admin for an organization would like to enable her users to 
>> access a SaaS application at her IdP. 
>> 
>> User experience: 
>> Admin authenticates to IdP in browser
>> Admin selects SaaS app to federate with from list at IdP
>> IdP optionally presents config options
>> IdP redirects Admin to SaaS app
>> Admin authenticates to SaaS app
>> SaaS app optionally gathers config options
>> SaaS app redirects admin to IdP
>> IdP confirms successful federation => OIDC / SAML and SCIM are now 
>> configured and working between IdP and SaaS App
>> Who else is interested in solving this?
>> 
>> Is there interest in working on this in either SCIM or OAUTH Wgs?
>> 
>> Any one in BA interested in meeting on this topic this week?
>> 
>> — Dick
>> ___
>> scim mailing list
>> s...@ietf.org
>> https://www.ietf.org/mailman/listinfo/scim
> ___
> scim mailing list
> s...@ietf.org
> https://www.ietf.org/mailman/listinfo/scim
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0

[Phil Hunt (IDM)]

I would like to have more discussion before wg adoption. 

I support the work and am willing to help. 

Phil

> On Apr 6, 2016, at 14:25, Hannes Tschofenig  wrote:
> 
> Hi all,
> 
> this is the call for adoption of 'Resource Indicators for OAuth 2.0', see
> http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/
> 
> Please let us know by April 20th whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth
> working group.
> 
> Note: If you already stated your opinion at the IETF meeting in Buenos
> Aires then you don't need to re-state your opinion, if you want.
> 
> The feedback at the BA IETF meeting was the following: ~10 persons
> for accepting the document and 0 persons against.
> 
> Ciao
> Hannes & Derek
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.1

[Phil Hunt (IDM)]

 

Existing implementations are for the large part ok and do not need these 
mitigations. 

Only the new use cases we have been discussing (configure on the fly and 
multi-as, etc) really need mitigation. 

The updated by approach seems like a good way to address the new cases. 

Phil

> On Apr 6, 2016, at 14:35, Hannes Tschofenig  wrote:
> 
> Hi all,
> 
> today we discussed the OAuth Authorization Server Mixup draft. We were
> wondering what types of threats the document should find solutions for.
> 
> We discussed various document handling approaches including
> * OAuth Mix-Up and Cut-and-Paste attacks documented in separate
> solution documents
> * combined solution document covering the OAuth Mix-Up and the
> Cut-and-Paste attacks.
> 
> Barry pointed out that these documents could update the OAuth base
> specification.
> 
> As a more radical change it was also suggested to revise RFC 6749 "OAuth
> 2.0 Authorization Framework" and RFC 6819 "OAuth 2.0 Threat Model and
> Security Considerations".
> 
> Opening up the OAuth base specification obviously raises various other
> questions about cleaning up parts that go far beyond the AS mix-up and
> the cut-and-paste attacks. Other specifications, such as the Open
> Redirector, could be folded into such a new specification.
> 
> Derek and I would appreciate your input on this topic before we make a
> decision since it has significant impact on our work.
> 
> Ciao
> Hannes & Derek
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0

[Phil Hunt (IDM)]

With the process of immediate wglc I think we should review all documents more 
thoroughly before adoption. 

As I said I support the work. 

Phil

> On Apr 6, 2016, at 16:02, Hannes Tschofenig  wrote:
> 
> Phil,
> 
> we have discussed this concept already for years. In fact, it dates back
> to the days of the OAuth base specification and the security
> consideration section even talks about it.
> 
> We have had the content of this in the PoP key distribution draft and we
> are now moving it into a separate document.
> 
> I am not sure how much longer you want to discuss it.
> 
> Ciao
> Hannes
> 
> 
>> On 04/06/2016 08:07 PM, Phil Hunt (IDM) wrote:
>> I would like to have more discussion before wg adoption. 
>> 
>> I support the work and am willing to help. 
>> 
>> Phil
>> 
>>> On Apr 6, 2016, at 14:25, Hannes Tschofenig  
>>> wrote:
>>> 
>>> Hi all,
>>> 
>>> this is the call for adoption of 'Resource Indicators for OAuth 2.0', see
>>> http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/
>>> 
>>> Please let us know by April 20th whether you accept / object to the
>>> adoption of this document as a starting point for work in the OAuth
>>> working group.
>>> 
>>> Note: If you already stated your opinion at the IETF meeting in Buenos
>>> Aires then you don't need to re-state your opinion, if you want.
>>> 
>>> The feedback at the BA IETF meeting was the following: ~10 persons
>>> for accepting the document and 0 persons against.
>>> 
>>> Ciao
>>> Hannes & Derek
>>> 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.1

[Phil Hunt (IDM)]

t sufficiently 
>>> defined to come up with interoperable implementations. Additionally, there 
>>> seems to be a need to represent resource server locations (to not say 
>>> identities :-)) in this context.
>>> 
>>> To bundle all changes in a version 2.1 would also make communication into 
>>> the market much easier. 
>>> 
>>> best regards,
>>> Torsten.
>>> 
>>>> Am 06.04.2016 um 16:05 schrieb George Fletcher :
>>>> 
>>>> I'd definitely prefer a single solution document to many little ones that 
>>>> have to be combined to actually build a secure solution. It's already 
>>>> getting complex with the additional specs that have been added.
>>>> 
>>>> Additionally, I'm not against working on OAuth 2.1.
>>>> 
>>>> Thanks,
>>>> George
>>>> 
>>>>> On 4/6/16 2:06 PM, Phil Hunt (IDM) wrote:
>>>>> 
>>>>> Existing implementations are for the large part ok and do not need these 
>>>>> mitigations.
>>>>> 
>>>>> Only the new use cases we have been discussing (configure on the fly and 
>>>>> multi-as, etc) really need mitigation.
>>>>> 
>>>>> The updated by approach seems like a good way to address the new cases.
>>>>> 
>>>>> Phil
>>>>> 
>>>>>> On Apr 6, 2016, at 14:35, Hannes Tschofenig  
>>>>>> wrote:
>>>>>> 
>>>>>> Hi all,
>>>>>> 
>>>>>> today we discussed the OAuth Authorization Server Mixup draft. We 
>>>>>> were wondering what types of threats the document should find solutions 
>>>>>> for.
>>>>>> 
>>>>>> We discussed various document handling approaches including
>>>>>> * OAuth Mix-Up and Cut-and-Paste attacks documented in separate 
>>>>>> solution documents
>>>>>> * combined solution document covering the OAuth Mix-Up and the 
>>>>>> Cut-and-Paste attacks.
>>>>>> 
>>>>>> Barry pointed out that these documents could update the OAuth base 
>>>>>> specification.
>>>>>> 
>>>>>> As a more radical change it was also suggested to revise RFC 6749 
>>>>>> "OAuth
>>>>>> 2.0 Authorization Framework" and RFC 6819 "OAuth 2.0 Threat Model 
>>>>>> and Security Considerations".
>>>>>> 
>>>>>> Opening up the OAuth base specification obviously raises various 
>>>>>> other questions about cleaning up parts that go far beyond the AS 
>>>>>> mix-up and the cut-and-paste attacks. Other specifications, such 
>>>>>> as the Open Redirector, could be folded into such a new specification.
>>>>>> 
>>>>>> Derek and I would appreciate your input on this topic before we 
>>>>>> make a decision since it has significant impact on our work.
>>>>>> 
>>>>>> Ciao
>>>>>> Hannes & Derek
>>>>>> 
>>>>>> 
>>>>>> ___
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fw
>>>>>> w
>>>>>> w
>>>>>> .ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40mi
>>>>>> c
>>>>>> r
>>>>>> osoft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91a
>>>>>> b
>>>>>> 2
>>>>>> d7cd011db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%
>>>>>> 3
>>>>>> d
>>>>> ___
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.
>>>>> ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40micr
>>>>> o
>>>>> s
>>>>> oft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d
>>>>> 7 c 
>>>>> d011db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d
>>>> 
>>>> ___
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.
>>>> i
>>>> etf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40micros
>>>> o
>>>> f
>>>> t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd
>>>> 0
>>>> 1 1db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d
>>> 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.
>>> i 
>>> etf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microso
>>> f
>>> t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd0
>>> 1 1db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d
>>> 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Regarding using resource indicator to solve resource config issue

[Phil Hunt (IDM)]

I am finding I am not happy with solving the bad resource endpoint config issue 
with resource indicator. At best I see this as a special use draft for things 
like collab services or things which aren't resource owner centric. 

Yet resource endpoint config is a concern for all clients that configure on the 
fly. Is it reasonable to make resource indicator mandatory for all clients? 
Probably not. 

As OAuth depends primarily on TLS, it feels wrong not to have a solution that 
confirms the server host names are correct either via config lookup or some 
other mechanism. 

Tokbind is also a solution but I suspect it may only appeal to large scale 
service providers and may be further off as we wait for load balancers to 
support tokbind. Also there are issues with tokbind on initial user binding 
where the mitm attack might itself establish its own token binding. I have to 
think this through some to confirm. But the issue of worry is what is happening 
on initialization and first use if the hacker has already interceded a mitm. 
That would make validation at config time still critical. 

Hopefully somebody can arrive at an alternative for broader oauth use cases. 

Phil
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Regarding using resource indicator to solve resource config issue

[Phil Hunt (IDM)]

I am objecting to modifying the protocol in the default case as a majority do 
not need RI in the case of fixed endpoints. 

Migration would be challenging because the change is breaking and affects 
existing clients. 

Dynamic discovery are up and coming cases and a relatively green field. Dealing 
with it at configuration/discovery makes broader sense as it has no impact on 
existing clients. 

Phil

> On Apr 11, 2016, at 12:18, Brian Campbell  wrote:
> 
> I'm not sure where the idea that it's only applicable to special uses like 
> collaboration services is coming from. The pattern described in the draft 
> (using a different parameter name but otherwise the same) is deployed and 
> in-use for normal OAuth cases including and especially the resource owner 
> centric ones. 
> 
> 
>> On Mon, Apr 11, 2016 at 11:33 AM, Phil Hunt (IDM)  
>> wrote:
>> I am finding I am not happy with solving the bad resource endpoint config 
>> issue with resource indicator. At best I see this as a special use draft for 
>> things like collab services or things which aren't resource owner centric.
>> 
>> Yet resource endpoint config is a concern for all clients that configure on 
>> the fly. Is it reasonable to make resource indicator mandatory for all 
>> clients? Probably not.
>> 
>> As OAuth depends primarily on TLS, it feels wrong not to have a solution 
>> that confirms the server host names are correct either via config lookup or 
>> some other mechanism.
>> 
>> Tokbind is also a solution but I suspect it may only appeal to large scale 
>> service providers and may be further off as we wait for load balancers to 
>> support tokbind. Also there are issues with tokbind on initial user binding 
>> where the mitm attack might itself establish its own token binding. I have 
>> to think this through some to confirm. But the issue of worry is what is 
>> happening on initialization and first use if the hacker has already 
>> interceded a mitm. That would make validation at config time still critical.
>> 
>> Hopefully somebody can arrive at an alternative for broader oauth use cases.
>> 
>> Phil
>> ___
>> 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] Regarding using resource indicator to solve resource config issue

[Phil Hunt (IDM)]

John's assertion that RI can be used to detect mis-configured clients would 
make it mandatory. 

To avoid that we need a config time solution for misconfiguration. 

Phil

> On Apr 12, 2016, at 01:30, Sergey Beryozkin  wrote:
> 
> Hi
>> On 11/04/16 23:19, Phil Hunt (IDM) wrote:
>> I am objecting to modifying the protocol in the default case as a
>> majority do not need RI in the case of fixed endpoints.
>> 
>> Migration would be challenging because the change is breaking and
>> affects existing clients.
> How does it break the existing clients given this is an optional feature ? 
> Can you please describe the situation where the existing clients get broken ?
> 
> Brian, would it make sense to update the text to mention that the clients do 
> not have to be directly configured and instead it can be set during the 
> registration time, so that the property gets seamlessly linked to client 
> access tokens, etc, without the client applications having to be set up with 
> the resource indicators manually ?
> 
> Thanks, Sergey
> 
>> Dynamic discovery are up and coming cases and a relatively green field.
>> Dealing with it at configuration/discovery makes broader sense as it has
>> no impact on existing clients.
>> 
>> Phil
>> 
>> On Apr 11, 2016, at 12:18, Brian Campbell > <mailto:bcampb...@pingidentity.com>> wrote:
>> 
>>> I'm not sure where the idea that it's only applicable to special uses
>>> like collaboration services is coming from. The pattern described in
>>> the draft (using a different parameter name but otherwise the same) is
>>> deployed and in-use for normal OAuth cases including and especially
>>> the resource owner centric ones.
>>> 
>>> 
>>> On Mon, Apr 11, 2016 at 11:33 AM, Phil Hunt (IDM)
>>> mailto:phil.h...@oracle.com>> wrote:
>>> 
>>>I am finding I am not happy with solving the bad resource endpoint
>>>config issue with resource indicator. At best I see this as a
>>>special use draft for things like collab services or things which
>>>aren't resource owner centric.
>>> 
>>>Yet resource endpoint config is a concern for all clients that
>>>configure on the fly. Is it reasonable to make resource indicator
>>>mandatory for all clients? Probably not.
>>> 
>>>As OAuth depends primarily on TLS, it feels wrong not to have a
>>>solution that confirms the server host names are correct either
>>>via config lookup or some other mechanism.
>>> 
>>>Tokbind is also a solution but I suspect it may only appeal to
>>>large scale service providers and may be further off as we wait
>>>for load balancers to support tokbind. Also there are issues with
>>>tokbind on initial user binding where the mitm attack might itself
>>>establish its own token binding. I have to think this through some
>>>to confirm. But the issue of worry is what is happening on
>>>initialization and first use if the hacker has already interceded
>>>a mitm. That would make validation at config time still critical.
>>> 
>>>Hopefully somebody can arrive at an alternative for broader oauth
>>>use cases.
>>> 
>>>Phil
>>>___
>>>OAuth mailing list
>>>OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> -- 
> Sergey Beryozkin
> 
> Talend Community Coders
> http://coders.talend.com/

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Regarding using resource indicator to solve resource config issue

[Phil Hunt (IDM)]

Phil

> On Apr 12, 2016, at 03:49, John Bradley  wrote:
> 
> We did agree in BA that if the client sends no resource the AS would audience 
> the AT per configured policy and reply to the client with additional 
> meta-data about what resources the AT can be used at.

We also agreed that was not a remedy for an attack where an attacker simply 
wants the token to use at the correct site to gain access to the resource. 

RI is no remedy for misconfiguration esp if it should be optional for the 
client. 
> 
> It should be obvious that this is in no way a breaking change.
> 
> The only clients that need to provide a resource are ones that are asking for 
> a token for a unknown resource, not something that is supported securely 
> currently or by Pil’s spec.   Or when down scoping  a RT with multiple 
> audiences so that the server can provide the correct token type/ claims / 
> encryption/ signing.   Can we agree that with symmetrically signed AT it is 
> not a good thing to use the same key for all RS?
> 
> At the moment this can sort of be done with scopes but the client needs much 
> more documentation about the scopes to understand the mapping between 
> resource and scope, or possibly discovery of meta-data about the resource, 
> something also not covered in Phil’s draft.
> 
> We can update the draft as an ID.  
> 
> This is essentially the audience part of the POP key distribution with the 
> addition of Nat’s meta-data for the token endpoint (in the existing JSON 
> rather than a new header)
> 
> We need to address this.  Discovery in general and Phil’s draft specifically 
> are not a replacement, even if we were to adopt them.
> 
> To Phil’s other question about token binding, no an attacker can’t usefully  
> MitM a token bound AT.  
> The private key is controlled by the client and never disclosed.  You can 
> give the token to a MitM attacker but they cannot use it anyplace even with 
> themselves as they don’t have the private key.   That is the security goal of 
> token binding.
> 
> John B.
> 
>> On Apr 12, 2016, at 4:30 AM, Sergey Beryozkin  wrote:
>> 
>> Hi
>>> On 11/04/16 23:19, Phil Hunt (IDM) wrote:
>>> I am objecting to modifying the protocol in the default case as a
>>> majority do not need RI in the case of fixed endpoints.
>>> 
>>> Migration would be challenging because the change is breaking and
>>> affects existing clients.
>> How does it break the existing clients given this is an optional feature ? 
>> Can you please describe the situation where the existing clients get broken ?
>> 
>> Brian, would it make sense to update the text to mention that the clients do 
>> not have to be directly configured and instead it can be set during the 
>> registration time, so that the property gets seamlessly linked to client 
>> access tokens, etc, without the client applications having to be set up with 
>> the resource indicators manually ?
>> 
>> Thanks, Sergey
>> 
>>> Dynamic discovery are up and coming cases and a relatively green field.
>>> Dealing with it at configuration/discovery makes broader sense as it has
>>> no impact on existing clients.
>>> 
>>> Phil
>>> 
>>> On Apr 11, 2016, at 12:18, Brian Campbell >> <mailto:bcampb...@pingidentity.com>> wrote:
>>> 
>>>> I'm not sure where the idea that it's only applicable to special uses
>>>> like collaboration services is coming from. The pattern described in
>>>> the draft (using a different parameter name but otherwise the same) is
>>>> deployed and in-use for normal OAuth cases including and especially
>>>> the resource owner centric ones.
>>>> 
>>>> 
>>>> On Mon, Apr 11, 2016 at 11:33 AM, Phil Hunt (IDM)
>>>> mailto:phil.h...@oracle.com>> wrote:
>>>> 
>>>>   I am finding I am not happy with solving the bad resource endpoint
>>>>   config issue with resource indicator. At best I see this as a
>>>>   special use draft for things like collab services or things which
>>>>   aren't resource owner centric.
>>>> 
>>>>   Yet resource endpoint config is a concern for all clients that
>>>>   configure on the fly. Is it reasonable to make resource indicator
>>>>   mandatory for all clients? Probably not.
>>>> 
>>>>   As OAuth depends primarily on TLS, it feels wrong not to have a
>>>>   solution that confirms the server host names are correct either
>>>>   via config lookup or some other mechanism.
>>>> 
>>>>

Re: [OAUTH-WG] Regarding using resource indicator to solve resource config issue

[Phil Hunt (IDM)]

To be clear what I am saying... RI should be considered on its own merits as an 
optional protocol extension. 

I do not believe it has merit when linking it to client mis-configuration 
detection. The issues should be kept separate. 

Phil

> On Apr 12, 2016, at 09:00, Phil Hunt (IDM)  wrote:
> 
> 
> 
> Phil
> 
>> On Apr 12, 2016, at 03:49, John Bradley  wrote:
>> 
>> We did agree in BA that if the client sends no resource the AS would 
>> audience the AT per configured policy and reply to the client with 
>> additional meta-data about what resources the AT can be used at.
> 
> We also agreed that was not a remedy for an attack where an attacker simply 
> wants the token to use at the correct site to gain access to the resource. 
> 
> RI is no remedy for misconfiguration esp if it should be optional for the 
> client. 
>> 
>> It should be obvious that this is in no way a breaking change.
>> 
>> The only clients that need to provide a resource are ones that are asking 
>> for a token for a unknown resource, not something that is supported securely 
>> currently or by Pil’s spec.   Or when down scoping  a RT with multiple 
>> audiences so that the server can provide the correct token type/ claims / 
>> encryption/ signing.   Can we agree that with symmetrically signed AT it is 
>> not a good thing to use the same key for all RS?
>> 
>> At the moment this can sort of be done with scopes but the client needs much 
>> more documentation about the scopes to understand the mapping between 
>> resource and scope, or possibly discovery of meta-data about the resource, 
>> something also not covered in Phil’s draft.
>> 
>> We can update the draft as an ID.  
>> 
>> This is essentially the audience part of the POP key distribution with the 
>> addition of Nat’s meta-data for the token endpoint (in the existing JSON 
>> rather than a new header)
>> 
>> We need to address this.  Discovery in general and Phil’s draft specifically 
>> are not a replacement, even if we were to adopt them.
>> 
>> To Phil’s other question about token binding, no an attacker can’t usefully  
>> MitM a token bound AT.  
>> The private key is controlled by the client and never disclosed.  You can 
>> give the token to a MitM attacker but they cannot use it anyplace even with 
>> themselves as they don’t have the private key.   That is the security goal 
>> of token binding.
>> 
>> John B.
>> 
>>> On Apr 12, 2016, at 4:30 AM, Sergey Beryozkin  wrote:
>>> 
>>> Hi
>>>> On 11/04/16 23:19, Phil Hunt (IDM) wrote:
>>>> I am objecting to modifying the protocol in the default case as a
>>>> majority do not need RI in the case of fixed endpoints.
>>>> 
>>>> Migration would be challenging because the change is breaking and
>>>> affects existing clients.
>>> How does it break the existing clients given this is an optional feature ? 
>>> Can you please describe the situation where the existing clients get broken 
>>> ?
>>> 
>>> Brian, would it make sense to update the text to mention that the clients 
>>> do not have to be directly configured and instead it can be set during the 
>>> registration time, so that the property gets seamlessly linked to client 
>>> access tokens, etc, without the client applications having to be set up 
>>> with the resource indicators manually ?
>>> 
>>> Thanks, Sergey
>>> 
>>>> Dynamic discovery are up and coming cases and a relatively green field.
>>>> Dealing with it at configuration/discovery makes broader sense as it has
>>>> no impact on existing clients.
>>>> 
>>>> Phil
>>>> 
>>>> On Apr 11, 2016, at 12:18, Brian Campbell >>> <mailto:bcampb...@pingidentity.com>> wrote:
>>>> 
>>>>> I'm not sure where the idea that it's only applicable to special uses
>>>>> like collaboration services is coming from. The pattern described in
>>>>> the draft (using a different parameter name but otherwise the same) is
>>>>> deployed and in-use for normal OAuth cases including and especially
>>>>> the resource owner centric ones.
>>>>> 
>>>>> 
>>>>> On Mon, Apr 11, 2016 at 11:33 AM, Phil Hunt (IDM)
>>>>> mailto:phil.h...@oracle.com>> wrote:
>>>>> 
>>>>>  I am finding I am not happy with solving the bad resource endpoint
>>>>>  config issue with resource indicator. At

Re: [OAUTH-WG] [COSE] [Ace] Call for adoption for draft-wahlstroem-ace-cbor-web-token-00

[Phil Hunt (IDM)]

I don't have this issue. I see your point, but I think the constrained branding 
makes it clear. 

IOW. When the specs say "constrained web" the use means to me that the tokens 
for the constrained set of binary protocols which all tend to be in parallel 
architecture with web apis anyway.  

Phil

> On May 10, 2016, at 05:57, Justin Richer  wrote:
> 
> You’re missing my original complaint: Until this token can be directly 
> encoded into web technologies, like HTTP headers and HTML pages, then it has 
> no business being called a “Web” anything. As it is, it’s a binary encoding 
> that would need an additional wrapper, like base64url perhaps, to be placed 
> into web spaces. It can be used in CoAP and native CBOR structures as-is, 
> which is what it’s designed to do. 
> 
> The “web” part of JWT is very important. A JWT can be used, as-is, in any 
> part of an HTTP message: headers, query, form, etc. It can also be encoded as 
> a string in other data structures in just about any language without any 
> additional transformation, including HTML, XML, and JSON. This makes the JWT 
> very “webby”, and this is a feature set that this new token doesn’t share. 
> Ergo, it has no business being called a “web” token regardless of its 
> heritage. 
> 
> Both CBOR Token and COSE Token are fine with me. 
> 
>  — Justin
> 
>> On May 10, 2016, at 3:50 AM, Mike Jones  wrote:
>> 
>> I also feel strongly that the name should remain CBOR Web Token.  CWT is a 
>> beneficiary of the intellectual and deployment heritage from the Simple Web 
>> Token (SWT) and JSON Web Token (JWT).  CWT is intentionally parallel to JWT. 
>>  The name should stay parallel as well.
>>  
>> The “Web” part of the “CBOR Web Token” name can be taken as a reference to 
>> the Web of Things (see https://en.wikipedia.org/wiki/Web_of_Things).  As 
>> Erik correctly points out JSON is not the only data representation that 
>> makes things in the Web and the Web of Things.
>>  
>>   -- Mike
>>  
>> From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Erik Wahlström
>> Sent: Tuesday, May 10, 2016 1:44 AM
>> To: Justin Richer 
>> Cc: Kathleen Moriarty ; Kepeng Li 
>> ; a...@ietf.org; Carsten Bormann ; 
>> Hannes Tschofenig ;  
>> ; cose 
>> Subject: Re: [Ace] [COSE] Call for adoption for 
>> draft-wahlstroem-ace-cbor-web-token-00
>>  
>> Or keep the CBOR Web Token (CWT) for two major reasons:
>> - To show the very close relationship to JWT. It relies heavily on JWT and 
>> it's iana registry. It is essentially a JWT but in CBOR/COSE instead of 
>> JSON/JOSE.
>> - I would not say that JWT is the only format that works for the web, and 
>> it's even used in other, non-traditional, web protocols. That means I don't 
>> have a problem with the W in CWT at all. Why would JSON be the only web 
>> protocol?
>>  
>> Then we also have one smaller (a lot smaller) reason, it's the fact that it 
>> can be called "cot" just like JWT is called a "jot" and I figured that our 
>> "cozy chairs" would very much like that fact because then it's essentially a 
>> "cozy cot" :)
>>  
>> / Erik
>>  
>>  
>> On Tue, May 10, 2016 at 2:49 AM, Justin Richer  wrote:
>> We can also call it the “COSE Token”. As a chair of the COSE working group, 
>> I’m fine with that amount of co-branding.
>> 
>>  — Justin
>> 
>> > On May 9, 2016, at 9:31 AM, Carsten Bormann  wrote:
>> >
>> >> draft-ietf-ace-cbor-token-00.txt;
>> >
>> > For the record, I do not think that ACE has a claim on the term "CBOR
>> > Token".  While the term token is not used in RFC 7049, there are many
>> > tokens that could be expressed in CBOR or be used in applying CBOR to a
>> > problem.
>> >
>> > ACE CBOR Token is fine, though.
>> > (Or, better, CBOR ACE Token, CAT.)
>> >
>> > Grüße, Carsten
>> >
>> > ___
>> > COSE mailing list
>> > c...@ietf.org
>> > https://www.ietf.org/mailman/listinfo/cose
>> 
>> ___
>> Ace mailing list
>> a...@ietf.org
>> https://www.ietf.org/mailman/listinfo/ace
> 
> ___
> COSE mailing list
> c...@ietf.org
> https://www.ietf.org/mailman/listinfo/cose
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [Technical Errata Reported] RFC6749 (4749)

[Phil Hunt (IDM)]

This is off topic for the errata process. This is not the place to propose a 
re-write. 

As one of the authors of the threat model and sec considerations I think we 
covered this to too much. :-) Justin's comments are spot on. 

This has nothing to do with user authentication. 

Phil

> On Jul 28, 2016, at 8:09 PM, Jim Manico  wrote:
> 
> Thank you Justin, comments inline.
> 
>> These are client secrets, not user passwords, so they’re supposed to be high 
>> entropy and not human-memorable (or human-typable really).
> 
> This still sounds like sensitive data, and I don't understand the relevance 
> of "human memorable". If time allows can you tell me more?
> 
>> Also, this needs to be used over TLS.
> 
> Sure, but the problems of HTTP Basic are well established and go beyond TLS 
> (no timeout, included in each request, cached by the browser for that window 
> session, etc).
> 
>> The connection requires TLS anyway because the tokens returned (or the token 
>> keys in the OAuth PoP case) also need to be protected, regardless of how you 
>> hash the client’s secret. With that in mind, Digest doesn’t buy you much.
> 
> So this looks like a way to transport the client id and secret. Wouldn't some 
> form of "strong authentication" like mutual TLS or similar be a better 
> default standard? The OAuth 2 threat model makes this exact recommendation.
> 
> Respectfully,
> --
> Jim Manico
> @Manicode
> Secure Coding Education
> +1 (808) 652-3805
> 
>> On Jul 28, 2016, at 4:25 PM, Justin Richer  wrote:
>> 
>> These are client secrets, not user passwords, so they’re supposed to be high 
>> entropy and not human-memorable (or human-typable really). Also, this needs 
>> to be used over TLS. The connection requires TLS anyway because the tokens 
>> returned (or the token keys in the OAuth PoP case) also need to be 
>> protected, regardless of how you hash the client’s secret. With that in 
>> mind, Digest doesn’t buy you much.
>> 
>> — Justin
>> 
>>> On Jul 26, 2016, at 8:08 PM, Jim Manico  wrote:
>>> 
>>> Please forgive me if this comment is out of order or inappropriate in any 
>>> way...
>>> 
>>> ...but why is HTTP Basic even being discussed in 2016? It has horrific 
>>> security properties at multiple levels; shouldn't we at least move to HTTP 
>>> Digest if not something stronger?
>>> 
>>> Regards.
>>> --
>>> Jim Manico
>>> @Manicode
>>> 
 On Jul 26, 2016, at 4:48 PM, RFC Errata System  
 wrote:
 
 The following errata report has been submitted for RFC6749,
 "The OAuth 2.0 Authorization Framework".
 
 --
 You may review the report below and at:
 http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=4749
 
 --
 Type: Technical
 Reported by: Phil Hunt 
 
 Section: 2.3.1
 
 Original Text
 -
 Clients in possession of a client password MAY use the HTTP Basic
 authentication scheme as defined in [RFC2617] to authenticate with
 the authorization server.  The client identifier is encoded using the
 "application/x-www-form-urlencoded" encoding algorithm per
 Appendix B, and the encoded value is used as the username; the client
 password is encoded using the same algorithm and used as the
 password.  The authorization server MUST support the HTTP Basic
 authentication scheme for authenticating clients that were issued a
 client password.
 
 Corrected Text
 --
 Clients in possession of a client password MAY use the HTTP Basic
 authentication scheme as defined in [RFC2617] to authenticate with
 the authorization server.  The client identifier is encoded using the
 "application/x-www-form-urlencoded" encoding algorithm per
 Appendix B, and the encoded value is used as the username; the client
 password is encoded using the same algorithm and used as the
 password. The url encoded values are then encoded as defined in
 [RFC2617]. The authorization server MUST support the HTTP Basic
 authentication scheme for authenticating clients that were issued a
 client password.
 
 Notes
 -
 It was not clear to some implementers that the intention is a 2-step 
 encoding. First for special characters and second the 2617 base 64 
 encoding.  Implementers thought 6749 was in conflict with 2617.
 
 To avoid inter-op issues, a new clarifying sentence is proposed.
 "The url encoded values are then encoded as defined in [RFC2617]."
 
 Instructions:
 -
 This erratum is currently posted as "Reported". If necessary, please
 use "Reply All" to discuss whether it should be verified or
 rejected. When a decision is reached, the verifying party (IESG)
 can log in to change the status and edit the report, if necessary. 
 
 --
 RFC6749 (draft-ietf-oauth-v2-31)
 --

Re: [OAUTH-WG] Using IdToken instead of Access token

[Phil Hunt (IDM)]

You might be munging two different flows with different semantics together. 

First flow is use oidc to authen the user to the client. 

Second flow is normal oauth authorization to get an at to access the resource. 

Often the OP AS is different from the RS's AS and the rs needs a proper 
"delegation" access token. 

Phil

> On Aug 4, 2016, at 6:00 AM, Mike Schwartz  wrote:
> 
> Sergey,
> 
> Since no one answered your question, let me pose a few questions to your 
> questions!
> 
> Wouldn't it give you more flexibility to issue a different token to
> represent access to the RS API? In terms of passing user claims,
> couldn't this be done via parameters in the API? Are you trying to do
> more with OpenID Connect than was anticpiated in the design?
> The id_token has an audience, are you including more than one client in that
> audience? Would it make sense to look at token exchange and downscope the 
> token?
> If you are looking for a profile of OAuth2, might UMA work?
> 
> I think you're not alone in wondering what the answer to all these questions 
> are..
> 
> - Mike
> 
> 
> -
> Michael Schwartz
> Gluu
> http://gluu.org
> 
>> Message: 3
>> Date: Wed, 3 Aug 2016 11:08:29 +0100
>> From: Sergey Beryozkin 
>> To: "oauth@ietf.org" 
>> Subject: [OAUTH-WG] Using IdToken instead of Access token
>> Message-ID: 
>> Content-Type: text/plain; charset=windows-1252; format=flowed
>> Hi All
>> I hope this question is better suited for this list. Will have no
>> problems redirecting it to the openid-connect list instead.
>> Consider a user working with the client web application (OIDC RP) which
>> authenticates the user with the OIDC authorization code flow at the end
>> of which the client gets AccessToken + IdToken. Next the user requests
>> something from the client which needs to access the RS to complete this
>> request.
>> And the idea is to have the client pass IdToken to RS and use various
>> user claims inside this IdToken to enforce the access control at the RS
>> level. My position it is likely wrong but I guess I may be missing
>> something that will be either in favor or against it.
>> The reason I think it is wrong is that if the client is using a code
>> flow then the right approach for staying within the OAuth2 'world' is to
>> use the access token to talk to RS and use IdToken only for the purpose
>> of interacting with the user. The access token represents a proper user
>> authorization and can have the extra scopes in addition to "oidc" which
>> RS can depend upon in its access control restrictions.
>> Next I'm arguing that if the IdToken is used instead then it is the case
>> of the client impersonating the user. And refer to the STS for the REST
>> of Us draft (I have a separate series of question on that draft). I'm
>> saying the impersonation can work but ignoring the access tokens
>> completely will make the overall solution much less flexible.
>> I'd like to ask for some advice/guidance:
>> - Is it a good idea at all for the client to use IdToken instead of
>> AccessToken as explored above ? I suppose it can work, in the code flow
>> the client gets the access token which, by default, only allows to
>> access UserInfo. Perhaps the client impersonating IdToken for the
>> purpose of accessing RS is not too bad after all.
>> - Assuming the impersonation is OK, what is the right criteria for the
>> client to choose to work with IdToken instead of the access token when
>> accessing the immediate RS. It seems like if the impersonation is OK for
>> the client to do then why have access tokens at all...
>> - Assuming the impersonation is OK, does STS For the REST of Us shows
>> the right and the only way it needs to be done ? I can imagine how it
>> will work for the web app clients, but what about Implicit Clients.
>> Many thanks, Sergey
> 
> ___
> 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] Using IdToken instead of Access token

[Phil Hunt (IDM)]

This is as bad as assuming an access token means someone was authenticated. 

In this case the audience of the id token is not the resource and other badness 
may ensue. 

Phil

> On Aug 4, 2016, at 8:17 AM, Sergey Beryozkin  wrote:
> 
> Hi Phil
> 
>> On 04/08/16 15:01, Phil Hunt (IDM) wrote:
>> You might be munging two different flows with different semantics together.
>> 
>> First flow is use oidc to authen the user to the client.
>> 
>> Second flow is normal oauth authorization to get an at to access the 
>> resource.
>> 
>> Often the OP AS is different from the RS's AS and the rs needs a proper 
>> "delegation" access token.
> Indeed, this is more or less what I've been saying in our private discussions.
> 
> But as I said to in my response to Mike, I see a demand to have IdToken 
> propagated and given the token exchange draft has a dedicated 'impersonation' 
> section I'm assuming there's a need for it.
> 
> For example, I was checking the archives, could see Brian Campbell quoting 
> Vittorio Bertocci:
> "To summarize our main use case: we use [a token exchange like protocol] for 
> achieving user impersonation thru tiers, or delegation for confidential 
> clients which do not have any web UX..."
> 
> The former case there suggests that if a client has a web UI they 
> authenticate the user first and then start impersonating.
> 
> I'm advocating for the clients to use the access tokens. The clients can 
> requests the extra scopes while authenticating the user and if the user 
> approves these scopes the client can continue using AT on behalf of the 
> client, and using IdToken to only interact with the user.
> 
> But I'm finding it difficult to explain (show a clear differentiator) when 
> the client should use AT and when they should use IdToken to impersonate a 
> user and get a new token (via the token exchange)...
> 
> Sergey
>> 
>> Phil
>> 
>>> On Aug 4, 2016, at 6:00 AM, Mike Schwartz  wrote:
>>> 
>>> Sergey,
>>> 
>>> Since no one answered your question, let me pose a few questions to your 
>>> questions!
>>> 
>>> Wouldn't it give you more flexibility to issue a different token to
>>> represent access to the RS API? In terms of passing user claims,
>>> couldn't this be done via parameters in the API? Are you trying to do
>>> more with OpenID Connect than was anticpiated in the design?
>>> The id_token has an audience, are you including more than one client in that
>>> audience? Would it make sense to look at token exchange and downscope the 
>>> token?
>>> If you are looking for a profile of OAuth2, might UMA work?
>>> 
>>> I think you're not alone in wondering what the answer to all these 
>>> questions are..
>>> 
>>> - Mike
>>> 
>>> 
>>> -
>>> Michael Schwartz
>>> Gluu
>>> http://gluu.org
>>> 
>>>> Message: 3
>>>> Date: Wed, 3 Aug 2016 11:08:29 +0100
>>>> From: Sergey Beryozkin 
>>>> To: "oauth@ietf.org" 
>>>> Subject: [OAUTH-WG] Using IdToken instead of Access token
>>>> Message-ID: 
>>>> Content-Type: text/plain; charset=windows-1252; format=flowed
>>>> Hi All
>>>> I hope this question is better suited for this list. Will have no
>>>> problems redirecting it to the openid-connect list instead.
>>>> Consider a user working with the client web application (OIDC RP) which
>>>> authenticates the user with the OIDC authorization code flow at the end
>>>> of which the client gets AccessToken + IdToken. Next the user requests
>>>> something from the client which needs to access the RS to complete this
>>>> request.
>>>> And the idea is to have the client pass IdToken to RS and use various
>>>> user claims inside this IdToken to enforce the access control at the RS
>>>> level. My position it is likely wrong but I guess I may be missing
>>>> something that will be either in favor or against it.
>>>> The reason I think it is wrong is that if the client is using a code
>>>> flow then the right approach for staying within the OAuth2 'world' is to
>>>> use the access token to talk to RS and use IdToken only for the purpose
>>>> of interacting with the user. The access token represents a proper user
>>>> authorization and can have the extra scopes in addition to "oidc" which
>&

Re: [OAUTH-WG] Authentication Method Reference Values Document: IPR Confirmation

[Phil Hunt (IDM)]

I am aware of no IPR. 

Phil

> On Sep 19, 2016, at 2:26 AM, Mike Jones  wrote:
> 
> I am aware of no IPR on this specification.
> 
>-- Mike
> 
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
> Sent: Monday, September 19, 2016 2:21 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Authentication Method Reference Values Document: IPR 
> Confirmation
> 
> Hi Mike, Phil, Tony,
> 
> 
> I am working on the shepherd writeup for the AMR document:
> https://tools.ietf.org/html/draft-ietf-oauth-amr-values-02
> 
> One item in the template requires me to indicate whether each document author 
> has confirmed that any and all appropriate IPR disclosures required for full 
> conformance with the provisions of BCP 78 and BCP 79 have already been filed.
> 
> Could you please confirm?
> 
> Ciao
> Hannes
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Future of PoP Work

[Phil Hunt (IDM)]

While the tokbind seems strategic, there are concerns about universality. A 
chief barrier is getting all tls termination points to support - a matter of 
substantial time. 

There are also those that argue that we still need an app layer end-to-end 
solution that pop provides. 

That said, I am not sure pop is that useful without some form of 
request/response signing solution. 

I hate to say this but maybe we have to go with some form of encapsulation? Eg 
a signed http request within an http request? Ugh!

Phil

> On Oct 19, 2016, at 12:04 PM, Mike Jones  wrote:
> 
> 1.  We should continue the PoP work in the OAuth working group and not move 
> it to ACE.  (This was also discussed in the minutes at 
> https://www.ietf.org/proceedings/96/minutes/minutes-96-oauth.)
> 
> 2.  We should abandon the HTTP signing work.  It is both overly complicated 
> *and* incomplete - not a good combination.  This same combination is what let 
> people to abandon OAuth 1.0 in favor of WRAP and later OAuth 2.0.  We should 
> learn from our own mistakes. ;-)
> 
>-- Mike
> 
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
> Sent: Wednesday, October 19, 2016 2:45 PM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Future of PoP Work
> 
> Hi all,
> 
> two questions surfaced at the last IETF meeting, namely
> 
> 1) Do we want to proceed with the symmetric implementation of PoP or, 
> alternatively, do we want to move it over to the ACE working group?
> 
> 2) Do we want to continue the work on HTTP signing?
> 
> We would appreciate your input on these two questions.
> 
> Ciao
> Hannes & Derek
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Future of PoP Work

[Phil Hunt (IDM)]

Maybe if we reworked the signing doc so content types like xml and json could 
be signed?  

This would cover for the majority of web api cases. 

Wonder what the advice of the http wg would be on this. 

Phil

> On Oct 24, 2016, at 8:29 AM, Samuel Erdtman  wrote:
> 
> +1 on doing PoP work in this working group, including HTTP signing/MACing, I 
> don´t think the old HTTP signature document was that far from useful.
> 
> With the ACE work I like when it is possible to just map work done in the 
> OAuth and other working groups to the more optimized protocols. Some would 
> maybe say that it is sub-optimal that the protocol was not initially designed 
> for the constrained environment but I think the benefit of concept validation 
> from web is a bigger plus.
> 
> //Samuel
> 
>> On Sat, Oct 22, 2016 at 7:47 PM, Justin Richer  wrote:
>> I believe that the PoP work should stay in the working group, and that 
>> without a usable presentation mechanism such as an HTTP message signature 
>> the whole work is pointless. I agree with Mike that we should learn from our 
>> own mistakes — and that is precisely the direction that the current HTTP 
>> signing draft took. As a result, the base level of functionality is signing 
>> the token itself (with a timestamp/nonce) using the key. All of the fiddly 
>> HTTP bits that trip people up? Not only are they optional, but it’s 
>> explicitly declared what’s covered. Why? Because we’re learning from past 
>> mistakes.
>> 
>> I think that token binding is relying on a lot of “ifs” that aren’t real 
>> yet, and if those “ifs” become reality then it will be to the benefit of 
>> large internet companies over everyone else. Additionally, token binding in 
>> OAuth is far from the simple solution that it’s being sold as. The very 
>> nature of an access token goes against the original purpose of tying an 
>> artifact to a single presentation channel. OAuth clients in the real world 
>> need to be able to deal with multiple resource servers and dynamically 
>> deployed APIs, and the token binding protocol fundamentally assumes a world 
>> where two machines are talking directly to each other.
>> 
>> All that said, this working group has consistently shown resistance to 
>> solving this problem for many years, so the results of this query don’t at 
>> all surprise me.
>> 
>>  — Justin
>> 
>> > On Oct 19, 2016, at 11:45 AM, Hannes Tschofenig 
>> >  wrote:
>> >
>> > Hi all,
>> >
>> > two questions surfaced at the last IETF meeting, namely
>> >
>> > 1) Do we want to proceed with the symmetric implementation of PoP or,
>> > alternatively, do we want to move it over to the ACE working group?
>> >
>> > 2) Do we want to continue the work on HTTP signing?
>> >
>> > We would appreciate your input on these two questions.
>> >
>> > Ciao
>> > Hannes & Derek
>> >
>> > ___
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
> 
> ___
> 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] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

[Phil Hunt (IDM)]

+1

Phil

> On Nov 4, 2016, at 6:11 PM, John Bradley  wrote:
> 
> I can easily see Research and education publishing self signed certs in 
> meta-data that is then used for client authentication and other things.
> I don’t want to limit this to only CA issued certs where the client_id is in 
> the DN.Client_id tend not to be domain names currently.
> Looking up a raw key  provided via JWK in registration based on client_id 
> will be one way that people will use this.   Passing the cert is seen as just 
> a way of passing the key to many people.
> 
> I also understand the desire in ACE to save bytes.
> 
> If you are using self signed certs then including the client_id in the cert 
> vs as a parameter is a bit of a no op re size.
> 
> Perhaps if there is a common pattern we could document a IoT profile where ca 
> issued cert is used and what it would look like.
> 
> I have concerns that this may open a can of worms around what the CN would be 
> and the interpretations of use extensions if this is flagged as something 
> other than a host cert.What do devices do now when they are issued certs. 
>  Is there a common standard or is it by manufacturer.
> 
> My main concern would be to not hold up what should be a simple spec for the 
> server to server case, but am willing to accommodate IoT if possible.
> 
> Regards
> John B.
> 
>> On Oct 28, 2016, at 5:31 PM, Brian Campbell  
>> wrote:
>> 
>> Not wanting to add more meta parameters was a motivation. Also not being 
>> sure of how to enumerate the possible approaches. My thinking was also that 
>> there are a lot of factors involved and that it'd probably be better left to 
>> service documentation to describe things like what authorities are trusted 
>> and what the client to cert binding is. Like I said, we can look at adding 
>> more metadata, if there's some consensus to do so. But I worry that it'll 
>> just be bloat that doesn't really add value. 
>> 
>> I also think that, in many situations, it's unlikely that a cert will 
>> contain a client id anywhere as subject information. A client id is scoped 
>> to a particular authorization server and it's hard to imagine a CA issuing a 
>> cert with an identifier that's only meaningful in the context of some other 
>> entity like that. Maybe in a more closed system where the AS and an 
>> organizational CA are both in the same management/administrative domain but 
>> not in the more general case.   
>> 
>> 
>> 
>>> On Wed, Oct 26, 2016 at 8:42 PM, Vladimir Dzhuvinov 
>>>  wrote:
>>> I see. Do you reckon the AS could simply probe the likely cert places
>>> for containing the client_id? My reasoning is that there aren't that
>>> many places where you could stick the client_id (let me know if I'm
>>> wrong). If the AS is in doubt it will respond with invalid_client. I'm
>>> starting to think this can work quite well. No extra meta param will be
>>> needed (of which we have enough already).
>>> 
>>> On 22/10/16 01:51, Brian Campbell wrote:
>>> > I did consider something like that but stopped short of putting it in the
>>> > -00 document. I'm not convinced that some metadata around it would really
>>> > contribute to interop one way or the other. I also wanted to get the basic
>>> > concept written down before going too far into the weeds. But I'd be open
>>> > to adding something along those lines in future revisions, if there's some
>>> > consensus that it'd be useful.
>>> >
>>> > On Mon, Oct 17, 2016 at 2:47 AM, Vladimir Dzhuvinov 
>>> > >> >> wrote:
>>> >> Superb, I welcome that!
>>> >>
>>> >> Regarding https://tools.ietf.org/html/draft-campbell-oauth-tls-
>>> >> client-auth-00#section-5.2 :
>>> >>
>>> >> My concern is that the choice of how to bind the client identity is left
>>> >> to implementers, and that may eventually become an interop problem.
>>> >> Have you considered some kind of an open ended enumeration of the 
>>> >> possible
>>> >> binding methods, and giving them some identifiers or names, so that AS /
>>> >> OPs can advertise them in their metadata, and clients register 
>>> >> accordingly?
>>> >>
>>> >> For example:
>>> >>
>>> >> "tls_client_auth_bind_methods_supported" : [ "subject_alt_name_match",
>>> >> "subject_public_key_info_match" ]
>>> >>
>>> >>
>>> >> Cheers,
>>> >>
>>> >> Vladimir
>>> >>
>>> >> On 10/10/16 23:59, John Bradley wrote:
>>> >>
>>> >> At the request of the OpenID Foundation Financial Services API Working 
>>> >> group, Brian Campbell and I have documented
>>> >> mutual TLS client authentication.   This is something that lots of 
>>> >> people do in practice though we have never had a spec for it.
>>> >>
>>> >> The Banks want to use it for some server to server API use cases being 
>>> >> driven by new open banking regulation.
>>> >>
>>> >> The largest thing in the draft is the IANA registration of 
>>> >> “tls_client_auth” Token Endpoint authentication method for use in 
>>> >> Registration and discovery.
>>> >>
>>> >> The trust model is intentionally left open s

Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

[Phil Hunt (IDM)]

John's comments

Phil

> On Nov 7, 2016, at 8:43 AM, Samuel Erdtman  wrote:
> 
> Phil, what is your +1 referring to?
> 
> //Samuel
> 
>> On Sat, Nov 5, 2016 at 2:14 AM, Phil Hunt (IDM)  wrote:
>> +1
>> 
>> Phil
>> 
>>> On Nov 4, 2016, at 6:11 PM, John Bradley  wrote:
>>> 
>>> I can easily see Research and education publishing self signed certs in 
>>> meta-data that is then used for client authentication and other things.
>>> I don’t want to limit this to only CA issued certs where the client_id is 
>>> in the DN.Client_id tend not to be domain names currently.
>>> Looking up a raw key  provided via JWK in registration based on client_id 
>>> will be one way that people will use this.   Passing the cert is seen as 
>>> just a way of passing the key to many people.
>>> 
>>> I also understand the desire in ACE to save bytes.
>>> 
>>> If you are using self signed certs then including the client_id in the cert 
>>> vs as a parameter is a bit of a no op re size.
>>> 
>>> Perhaps if there is a common pattern we could document a IoT profile where 
>>> ca issued cert is used and what it would look like.
>>> 
>>> I have concerns that this may open a can of worms around what the CN would 
>>> be and the interpretations of use extensions if this is flagged as 
>>> something other than a host cert.What do devices do now when they are 
>>> issued certs.  Is there a common standard or is it by manufacturer.
>>> 
>>> My main concern would be to not hold up what should be a simple spec for 
>>> the server to server case, but am willing to accommodate IoT if possible.
>>> 
>>> Regards
>>> John B.
>>> 
>>>> On Oct 28, 2016, at 5:31 PM, Brian Campbell  
>>>> wrote:
>>>> 
>>>> Not wanting to add more meta parameters was a motivation. Also not being 
>>>> sure of how to enumerate the possible approaches. My thinking was also 
>>>> that there are a lot of factors involved and that it'd probably be better 
>>>> left to service documentation to describe things like what authorities are 
>>>> trusted and what the client to cert binding is. Like I said, we can look 
>>>> at adding more metadata, if there's some consensus to do so. But I worry 
>>>> that it'll just be bloat that doesn't really add value. 
>>>> 
>>>> I also think that, in many situations, it's unlikely that a cert will 
>>>> contain a client id anywhere as subject information. A client id is scoped 
>>>> to a particular authorization server and it's hard to imagine a CA issuing 
>>>> a cert with an identifier that's only meaningful in the context of some 
>>>> other entity like that. Maybe in a more closed system where the AS and an 
>>>> organizational CA are both in the same management/administrative domain 
>>>> but not in the more general case.   
>>>> 
>>>> 
>>>> 
>>>>> On Wed, Oct 26, 2016 at 8:42 PM, Vladimir Dzhuvinov 
>>>>>  wrote:
>>>>> I see. Do you reckon the AS could simply probe the likely cert places
>>>>> for containing the client_id? My reasoning is that there aren't that
>>>>> many places where you could stick the client_id (let me know if I'm
>>>>> wrong). If the AS is in doubt it will respond with invalid_client. I'm
>>>>> starting to think this can work quite well. No extra meta param will be
>>>>> needed (of which we have enough already).
>>>>> 
>>>>> On 22/10/16 01:51, Brian Campbell wrote:
>>>>> > I did consider something like that but stopped short of putting it in 
>>>>> > the
>>>>> > -00 document. I'm not convinced that some metadata around it would 
>>>>> > really
>>>>> > contribute to interop one way or the other. I also wanted to get the 
>>>>> > basic
>>>>> > concept written down before going too far into the weeds. But I'd be 
>>>>> > open
>>>>> > to adding something along those lines in future revisions, if there's 
>>>>> > some
>>>>> > consensus that it'd be useful.
>>>>> >
>>>>> > On Mon, Oct 17, 2016 at 2:47 AM, Vladimir Dzhuvinov 
>>>>> > >>>> >> wrote:
>>>>> >> Sup

Re: [OAUTH-WG] Comments on draft-jones-oauth-resource-metadata-00

[Phil Hunt (IDM)]

For example scim has many resources. But it is reasonable to discover at its 
root since clients may ask for other resources. The as would not likely change 
across a single scim provider. 

Phil

> On Nov 13, 2016, at 5:27 PM, Torsten Lodderstedt  
> wrote:
> 
> I see your point but do you really think this is needed and efficient enough 
> for practical use?
> 
> Basing metadata handling on single resources (distinct URLs including 
> different query parameters, right?) in my opinion means:
> - the client needs to discovery the AS for every of those URLs
> - the client needs to acquire an access token per URL
> - I'm not quite sure what it means when it comes to token binding
> 
> I think it would be good idea to have a container on a more coarse grain 
> level in order to make that more efficient. If every resource (distinct URL) 
> belongs to such a container (let's call it resource server or something 
> else), the client-side handling should become easier.
> 
> BTW: we don't have different meta data for token endpoint and authorization 
> endpoint of a particular AS, right? So the comparision does not completely 
> fit.
> 
> What do you think?
> 
> best regards,
> Torsten.
> 
> 
> 
>> Am 13.11.2016 um 15:37 schrieb Mike Jones:
>> Actually, it’s intentionally a particular resource that the metadata applies 
>> to – exactly as the AS metadata applies to a particular AS.  It is *not* 
>> metadata about all resources that might be managed by a resource server, 
>> just as the AS metadata is not about all ASs that a particular server (such 
>> as a multi-tenant server) might manage.
>>  
>> Bear in mind that just as different ASs are likely to use different keys for 
>> security reasons, even if they are on the same physical server – such as in 
>> the multi-tenant case, different resources need to be able to use different 
>> keys, even if they are hosted at the same resource server.  That mandates 
>> the metadata being resource-specific.
>>  
>> For what it’s worth, if we ever do an OAuth 3.0, I believe we should get rid 
>> of the “resource server” term entirely.  It doesn’t have any actionable 
>> semantics tied to it and its existence only encourages confusion.
>>  
>> Thanks for reading the draft, Torsten.
>>  
>>-- Mike
>>  
>> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] 
>> Sent: Sunday, November 13, 2016 2:32 PM
>> To: Mike Jones ; oauth@ietf.org
>> Cc: gffle...@aol.com
>> Subject: Re: [OAUTH-WG] Comments on draft-jones-oauth-resource-metadata-00
>>  
>> Hi Mike,
>> 
>> just read your spec and I'm also a bit confused about the "resource" meta 
>> data element in section 2.
>> 
>> I would assume the metadata are provided for a certain resource server 
>> managing a set of resources in a particular administrative domain. So I 
>> would prefer to name the respective element "resource_server". In the 
>> example George gave the URL would be 
>> "https://idp.example.com/tenant//". Resource managed by a 
>> particular resource server could use sub-paths of the respective URL, such 
>> as " https://idp.example.com/tenant//users/".
>> 
>> best regards,
>> Torsten.
>> 
>> Am 05.08.2016 um 02:10 schrieb George Fletcher:
>> Mike, thanks for drafting and publishing these specifications. I have a 
>> couple of questions regarding the draft-jones-oauth-resource-metadata-00.
>> 
>> 1. Is a "protected resource" a server? or an actual API endpoint. The 
>> non-normative examples use /.well-known/oauth-protected-resource and 
>> /resource1/.well-known/oauth-protected-resource which is a little unclear. I 
>> think of "resource" as something like "Mail" or "Instant Messaging".
>> 
>> 2. Assuming that "protected resource" means an actual API endpoint, what is 
>> the expected location of the metadata for a fully REST compliant API where 
>> the full URL points to a specific resource and not the concept of a general 
>> API.
>> Using an example of an IdP that supports user management capabilities. Let's 
>> assume the IdP supports a REST API of...
>> 
>> CREATE -- POST https://idp.example.com/tenant//users
>> READ -- GET https://idp.example.com/tenant//users/
>> UPDATE -- PUT https://idp.example.com/tenant//users/
>> DELETE -- DELETE https://idp.example.com/tenant//users/
>> 
>> Assuming there are 3 tenants (tenantA, tenantB, tenantB) and lots of users. 
>> Where does the .well-known/oauth-protected-resource get added?
>> 
>>?? 
>> https://idp.example.com/tenant/tenantA/users/1232234/.well-known/oauth-protected-resource
>> 
>> In this case would not the oauth-protected-resource metadata be duplicated 
>> across the set of tenants and users? Is that the desired behavior?
>> Thanks,
>> George
>> 
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>  
> 
> ___
> OAuth mailing list
> OAuth

Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app

[Phil Hunt (IDM)]

+1 to AppAuth

One disturbing pattern I see for mobile apps relaying the idtoken is that the 
aud isn't checked by the AS in the Oauth exchange. This in part caused by the 
fact that the mobile app has two client-id identifiers. If the aud only has the 
clientid for the OIDC call this can be a problem if the AS doesn't know what 
that id is (since it didnt issue the id). If the issued id token does not have 
an aud value the AS can recognize it should be rejected.

Phil

> On Jan 25, 2017, at 12:24 PM, Brian Campbell  
> wrote:
> 
> +1 to the AppAuth pattern
> 
>> On Wed, Jan 25, 2017 at 12:48 PM,  wrote:
>> There are a number of patterns that people use.
>> 
>>  
>> 
>> I prefer the AppAuth pattern where the native app is a OAuth client to your 
>> server and you are protecting your API with OAuth.   Your AS becomes a 
>> Connect/SAML/Twitter auth/ Facebook etc relying party and uses federated or 
>> local authentication to issue tokens.  (this gives your backend API access 
>> to user info)
>> 
>>  
>> 
>> The other pattern is for the native app to be a Connect client to Google or 
>> other IdP and then passes a id_token (not access token) to your backend in 
>> some secure manor and your backend validates the signature on the id_token 
>> and that it was issued to your client (verification is essential) (the 
>> native app gets access to user info api)  You still have the problem of how 
>> you secure your API, as you need to exchange the validated id_token with 
>> something.   I thnk that doing this securely winds up being more complicated 
>> than the first option.
>> 
>>  
>> 
>> There are other options that may not be allowed by the IdP where your 
>> backend is the Connect client and has a client secret.  The mobile app makes 
>> the request and gets the code back.   It then sends code and pkce verifier 
>> to it’s backend and the server exchanges it with it’s secret to get a 
>> id_token and access token.   You still need to add security for your API.  
>> (custom scheme redirects for confidential clients may not be allowed 
>> depending on the Connect IdP)
>> 
>>  
>> 
>> I think the first option is the best design that gives the best long term 
>> design as new IdP can be added without changing the deployed app.
>> 
>>  
>> 
>>  
>> 
>> John B.
>> 
>>  
>> 
>> Sent from Mail for Windows 10
>> 
>>  
>> 
>> From: Dario Teixeira
>> Sent: January 25, 2017 7:59 AM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] OAuth2/OIDC for client-server mobile app
>> 
>>  
>> 
>> Hi,
>> 
>>  
>> 
>> I am building a mobile app and a server.  The mobile app fetches
>> 
>> user-specific data from the server, and therefore some sort of
>> 
>> authentication is required.  I would like to avoid the traditional
>> 
>> username+password scheme, and instead allow users to login via
>> 
>> Google or Facebook.  It seems the OAuth2-based OpenID Connect (OIDC)
>> 
>> is the recommended solution nowadays, so my question is about the
>> 
>> usage of OAuth2/OIDC in this scenario.
>> 
>>  
>> 
>> All OIDC docs and tutorials describe the interaction between three
>> 
>> parties: a Relying Party (RP), a User Agent (UA), and an OIDC
>> 
>> Provider (OIP).  There are however four parties in my scenario:
>> 
>> the mobile app, the server, the UA, and the OIP.  Which should
>> 
>> take the role of RP? I see two different ways to do this:
>> 
>>  
>> 
>> 1) The mobile app is the RP.  It even takes care of starting a
>> 
>> small web server to receive the data from the OIP.  At the end
>> 
>> of the interaction, the mobile app has a JWT signed by the OIP,
>> 
>> which it sends to the server, which must validate it using a
>> 
>> built-in list of OIP public signatures.
>> 
>>  
>> 
>> 2) The server is the RP.  When the user wishes to login, the mobile
>> 
>> app asks the server about the OIP's authorization endpoint.
>> 
>> The server provide the client with an URI whose redirect_uri
>> 
>> parameter points to the server.  All subsequent steps are
>> 
>> handled by the server.
>> 
>>  
>> 
>> Anyway, this seems like a fairly common scenario, and I would rather
>> 
>> follow some best-practices documentation instead of cooking up my
>> 
>> own schemes, like points 1 and 2 above.  Therefore, if there is
>> 
>> indeed such documentation, could someone please point me towards it?
>> 
>> And if not, which would be the recommended route, 1 or 2?
>> 
>>  
>> 
>> Thanks in advance for your attention!
>> 
>> Best regards,
>> 
>> Dario Teixeira
>> 
>>  
>> 
>> ___
>> 
>> OAuth mailing list
>> 
>> OAuth@ietf.org
>> 
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>>  
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app

[Phil Hunt (IDM)]

Afaik, the client app ends up with an access token (at). It never has to deal 
with id tokens. That all happens by way of the oauth AS server calling oidc 
itself.  Iow the oauth as is the oidc client.  

The code in the mobile client is trivial by comparison and does not need to do 
id token validation.

Phil

> On Jan 26, 2017, at 8:51 AM, Dario Teixeira  
> wrote:
> 
> Hi,
> 
>> https://tools.ietf.org/html/draft-ietf-oauth-native-apps [2]
>> They are OpenID foundation library's not Google's.   Google, Ping and
>> a number of others are active contributors if you look at the git
>> repositories.
> 
> Thanks for the link.  Perhaps I'm missing something, but the AppAuth
> pattern as described by this document represents only half the picture:
> at the end of the interaction, the native app is in possession of a
> token that authenticates the user.  However, my server cannot accept
> that token blindly!
> 
> Now, the way I would solve this is by keeping a hard-coded list of
> OpenID Provider public keys on my server, which I would use to
> verify that the token was indeed signed by the OIP.  Correct me
> if I'm wrong, but this also seems to be the recommended approach,
> right?
> 
> Thanks again for your time!
> Best regards,
> Dario Teixeira
> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app

[Phil Hunt (IDM)]

An seeing bad impls with justins pattern. In particular aud is not checked. 

The idp has to know the rsrc aud or the as has to know the client id the mobile 
app is using with OP provider. It ends up being complex with room for mistakes. 

Phil

> On Jan 26, 2017, at 10:00 AM, John Bradley  wrote:
> 
> Justin and I are recommending different approaches.  
> 
> My recommendation is that your app do appAuth to your server to get a access 
> token for your API.   Your server performs openid connect to google, SAML to 
> salesForce or Facebook Connect to Facebook and manages verification keys.   
> If the user is authenticated by the IdP it then authorizes your app on the 
> device to access your API.  
> 
> Justin is recommending that you build a client/relying party for each IdP 
> into your native app and pass the results of authentication ID_token, 
> Facebook signed request etc to your back end server for it to verify and 
> issue some cookie or webkey (probably not OAuth token) to your App for 
> accessing your API.  
> 
> My recommendation allowed you to protect your API using OAuth and to add or 
> modify IdP for your users without redeploying your native app.
> 
> Justin's approach avoids you needing to run a OAuth authorization server.   ( 
> He has a great open source one you could use).  
> 
> I think it is a style diffrence.  I think separating authorization and 
> authentication into two steps is cleaner and easier to maintain over the long 
> term.  
> 
> John B.  
> 
>> On Jan 26, 2017 8:51 AM, "Dario Teixeira"  wrote:
>> Hi,
>> 
>>> https://tools.ietf.org/html/draft-ietf-oauth-native-apps [2]
>>> 
>>> They are OpenID foundation library's not Google's.   Google, Ping and
>>> a number of others are active contributors if you look at the git
>>> repositories.
>> 
>> Thanks for the link.  Perhaps I'm missing something, but the AppAuth
>> pattern as described by this document represents only half the picture:
>> at the end of the interaction, the native app is in possession of a
>> token that authenticates the user.  However, my server cannot accept
>> that token blindly!
>> 
>> Now, the way I would solve this is by keeping a hard-coded list of
>> OpenID Provider public keys on my server, which I would use to
>> verify that the token was indeed signed by the OIP.  Correct me
>> if I'm wrong, but this also seems to be the recommended approach,
>> right?
>> 
>> Thanks again for your time!
>> Best regards,
>> Dario Teixeira
>> 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app

[Phil Hunt (IDM)]

What is concerning is that many are using resource owner flow so the client app 
can capture the uid/password under the assumption that the client needs to 
control the branding experience much has been done in silo approaches of the 
past. 

Adding to the confusion I note that many of the cloud provider site docs do not 
clearly distinguish mobile apps from web apps. Mobile app developers arw 
reading docs and telling me that oracle, google, and azure require the mobile 
app to register for an openid client id. 

Near as I can tell it is confusion over the difference between authz and authN. 

Phil

> On Jan 27, 2017, at 5:23 PM, ve7...@ve7jtb.com wrote:
> 
> It sounds like you are currently doing something like the OAuth resource 
> owner flow.
>  
> Is there a Authorization server currently associated with your resource 
> server?
>  
> If so you can change the OAuth flow you are using to the code one as 
> described in App Auth.
>  
> You still need to authenticate the users at your server using the current  
> username and password or via OpenID Connect to Google.
>  
> This is a two step process.  If you try to combine them by trying to make 
> your NA the connect client you may save a step in the short term but will 
> regret it in the long term when you decide to add another identity provider 
> like Microsoft etc.
>  
>  
> OAuth from the NA to your server to authorize the native app, and your server 
> to Google via Connect to Authenticate the user.
>  
> Regards
> John B.
>  
>  
>  
>  
> Sent from Mail for Windows 10
>  
> From: Dario Teixeira
> Sent: January 27, 2017 9:16 AM
> To: John Bradley
> Cc: Phil Hunt; IETF oauth WG
> Subject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app
>  
> Hi,
>  
> Thanks for your reply and your patience!
>  
> > Our recommendations are based on the assumption that the end state
> > is your app having an access token for your rest API.
> > If that is not what you are trying to do then we may be talking at
> > cross purposes.
>  
> Yes, that is exactly the end state I'm looking for, though there
> is a chance there is some misunderstanding about the whole picture.
> Allow me to summarise the current situation:
>  
> Users interact with a Native App (NA) running on a mobile phone.
> This app talks with a Resource Server (RS) via a RESTful API.
> Because there is private user data on the RS, the very first
> interaction between the NA and the RS is a login where the NA asks
> the user for an email+password combination, which it then sends
> to the RS.  If the email+password combination is valid, the RS
> replies with an access token that must be used by the NA in all
> its future requests.
>  
> This works fine, but has the disadvantage of requiring users to
> manually enter their email and password. The user experience would
> be much improved if users had the option to login using their Google,
> Facebook, or Github account.
>  
> Now, it is my understanding that OpenID Connect is the technology
> used nowadays to provide this sort of Single Sign-On.  All I'm
> looking for is documentation on how OIDC is actually implemented
> in this scenario.
>  
> Best regards,
> Dario Teixeira
>  
>  
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth for institutional users

[Phil Hunt (IDM)]

You are headed down the road to a very big domain called identity management 
and provisioning. 

You might want to look at SCIM (RFC7643, 7644) for a restful api pattern.

SCIM is usually OAuth enabled but the scopes/rights have not yet been 
standardized. There is however some obvious access control patterns that apply 
from the old ldap directory world.  

Phil

> On Feb 1, 2017, at 6:36 PM, Yunqi Zhang  wrote:
> 
> Hi all,
> 
> I'm working on a set of API endpoints to allow institutions to manage their 
> users and records, and their users to read their own records.
> 
> Specifically, each institution will get a {client_id} and a {secret} after 
> registering with us, which allows them to create users under its institution 
> using [POST https://hostname/users/]. Then the institution can also insert 
> records for each user using [POST https://hostname/users/:user_id/]. Once a 
> user has been created, he/she can read his/her own records using [GET 
> https://hostname/users/:user_id/].
> 
> In this process, there are two types of authentications I would like to 
> achieve, which I'm thinking about using oauth. However, I am super new on 
> oauth and have four questions.
> 
> Institution authentication (e.g., company FOO will have READ and WRITE access 
> to https://hostname/ to create users under its own institution, insert 
> records for specific users): (1) Since this part of the system will be 
> created and run by the institution, this should be a "client credential 
> grant" using {client_id} and {secret} of the institution, correct?
> 
> End-user authentication (e.g., user John Doe of company FOO will have READ 
> access to https://hostname/users/:john_doe_user_id/ to read his own personal 
> records): (2) Because this part of the system will probably run on the 
> web/mobile app created by company FOO, this should be a "resource owner 
> credential grant" using {username}, {password} of the specific user, correct?
> 
> (3) Because I am allow two types of different authentications, which will use 
> two types of different {access_token}s I assume, would that be something 
> weird (or hard to build) under the oauth model?
> 
> (4) What if the web/mobile app created by a subset of the companies already 
> has its own authentication and does not want to create another password for 
> each of its users, what should I do? For example, company FOO has its own 
> authentication for its web/mobile app and does not want to bother creating 
> another password for each of its user (i.e., requires only {username}), 
> whereas company BAR would like to create another password for each user 
> (i.e., requires {username} and {password}). What kind of authentication model 
> should I use for a scenario like this?
> 
> Thank you very much for your help!
> 
> Yunqi
> ___
> 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] Call for Adoption: Mutual TLS Profiles for OAuth Clients

[Phil Hunt (IDM)]

+1 for adoption 

Phil

> On Apr 20, 2017, at 10:40 AM, John Bradley  wrote:
> 
> I accept the adoption as a starting point.
> 
> John B.
> 
>> On Apr 20, 2017, at 1:32 PM, Hannes Tschofenig  
>> wrote:
>> 
>> Hi all,
>> 
>> based on the strong support for this document at the Chicago IETF
>> meeting we are issuing a call for adoption of the "Mutual TLS Profiles
>> for OAuth Clients" document, see
>> https://tools.ietf.org/html/draft-campbell-oauth-mtls-01
>> 
>> Please let us know by May 4th whether you accept / object to the
>> adoption of this document as a starting point for work in the OAuth
>> working group.
>> 
>> Ciao
>> Hannes & Rifaat
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] RFC 7009

[Phil Hunt (IDM)]

This is why i expect a secevent token revocation event to be defined to 
complement 7009 once secevents moves further along. 

We want to be able to know in near real time when a token is revoked to avoid 
constant checks to see if a token is still good. 

Phil

> On Jun 6, 2017, at 3:18 PM, Justin Richer  wrote:
> 
> That really depends on the nature of your tokens and how you manage their 
> internal validity. It’s really as soon as possible, isn’t it? If you can 
> invalidate it immediately, do that. In our implementation, we delete it from 
> the data store as soon as the revocation request comes in, which invalidates 
> it. Downstream RS’s might have cached introspection (RFC7662) results so 
> they’ll find out once their caches expire. If you’ve got some other 
> synchronization method that takes some time to propagate, then that’s going 
> to be the answer. All of this is dependent on your implementation and not on 
> the revocation protocol, but in all cases I see no reason to *wait* any 
> amount of time to revoke a token that’s been requested for revocation by a 
> client, for any reason. The client is effectively saying “if you see this 
> token again it isn’t from me”, which should be a good enough indication to 
> throw it out as soon as possible.
> 
> This all falls apart if you’re using self-contained tokens — there’s not a 
> good way to invalidate a self-contained token without using some kind of 
> lookup service. RFC7662 defines such a service for OAuth, but then your 
> tokens aren’t really fully self-contained anymore and you’re simply stuck 
> waiting for the compromised token to expire.
> 
>  — Justin
> 
>> On Jun 6, 2017, at 6:11 PM, Brig Lamoreaux  
>> wrote:
>> 
>> This is where we have the question around timeouts. If the client thinks its 
>> token is compromised, how long should 7009 take to invalidate.
>>  
>>  
>>  
>> From: Justin Richer [mailto:jric...@mit.edu] 
>> Sent: Tuesday, June 6, 2017 2:46 PM
>> To: Brig Lamoreaux 
>> Cc:  
>> Subject: Re: [OAUTH-WG] RFC 7009
>>  
>> 7009 doesn't, really. If the client thinks its token is compromised, it can 
>> revoke it using 7009. If the server decides the token is compromised, it 
>> invalidates it on its own, not involving 7009. The client finds out the 
>> token isn't good anymore the next time it tries to use the token -- OAuth 
>> clients always need to be prepared for their token not working at some 
>> point. Good news is that the remedy for having a token that doesn't work is 
>> to just do OAuth again.
>> 
>>  -- Justin
>> 
>>  
>> On 6/6/2017 5:43 PM, Brig Lamoreaux wrote:
>> Thanks for the reply. How do the RFC address a token that has been 
>> compromised?
>>  
>> From: Justin Richer [mailto:jric...@mit.edu] 
>> Sent: Tuesday, June 6, 2017 9:12 AM
>> To: Brig Lamoreaux 
>> Cc:  
>> Subject: Re: [OAUTH-WG] RFC 7009
>>  
>> OAuth doesn’t specify and specific timeout period, it’s up to the AS that 
>> issues the token to determine how long the token is good for. RFC7009 isn’t 
>> about timeout periods, it’s about the client proactively telling the AS that 
>> it doesn’t need a token anymore and the AS should throw it out, likely prior 
>> to any timeouts.
>>  
>>  — Justin
>>  
>> On May 25, 2017, at 12:23 PM, Brig Lamoreaux  
>> wrote:
>>  
>> Hi,
>> 
>> What is the specified timeout period to invalidate the token?
>>  
>> Brig Lamoreaux
>> Data Solution Architect
>> brig.lamore...@microsoft.com
>> 480-828-8707
>> US Desert/Mountain Tempe
>>  
>>  
>> 
>>  
>>  
>>  
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>  
>>  
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=7yMIczBrZnmQ14Nkf4MBGaIHnxRyiLGXB1Xhuxp1Ur0&s=TaKHdPgtEPkCV_YuOHlkoXRZJjf0k8Y4-yowD3YbhPw&e=
>  
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Authentication Method Reference Values is now RFC 8176

[Phil Hunt (IDM)]

Thank you Mike!

Phil

> On Jun 16, 2017, at 5:50 PM, Mike Jones  wrote:
> 
> The Authentication Method Reference Values specification is now RFC 8176.  
> The abstract describes the specification as:
>  
> The amr (Authentication Methods References) claim is defined and registered 
> in the IANA "JSON Web Token Claims" registry, but no standard Authentication 
> Method Reference values are currently defined. This specification establishes 
> a registry for Authentication Method Reference values and defines an initial 
> set of Authentication Method Reference values.
>  
> The specification defines and registers some Authentication Method Reference 
> values such as the following, which are already in use by some Google and 
> Microsoft products and OpenID specifications:
> “face” – Facial recognition
> “fpt” – Fingerprint
> “hwk” – Proof-of-possession of a hardware-secured key
> “otp” – One-time password
> “pin” – Personal Identification Number
> “pwd” – Password
> “swk” – Proof-of-possession of a software-secured key
> “sms” – Confirmation using SMS
> “user” – User presence test
> “wia” – Windows Integrated Authentication
> See https://www.iana.org/assignments/authentication-method-reference-values/ 
> for the full list of registered values.
>  
> Thanks to Caleb Baker, Phil Hunt, Tony Nadalin, and William Denniss, all of 
> whom substantially contributed to the specification.  Thanks also to the 
> OAuth working group members, chairs, area directors, and other IETF members 
> who helped refine the specification.
>  
> -- Mike
>  
> P.S.  This announcement was also posted at http://self-issued.info/?p=1701 
> and as @selfissued.
>  
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=c4h3kFuEtVHltGQ2Mo4qOxZUNOdHh2wTrdydAc7z8zQ&s=SzWRl9usAtrZR4uccnnP_Cq3XEwz6np9UhOmTtxF8rA&e=
>  
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] JSON Web Token Best Current Practices draft describing Explicit Typing

[Phil Hunt (IDM)]

+1

Thanks Mike. 

Phil

> On Jul 4, 2017, at 12:43 PM, Mike Jones  wrote:
> 
> The JWT BCP draft has been updated to describe the use of explicit typing of 
> JWTs as one of the ways to prevent confusion among different kinds of JWTs.  
> This is accomplished by including an explicit type for the JWT in the “typ” 
> header parameter.  For instance, the Security Event Token (SET) specification 
> now uses the “application/secevent+jwt” content type to explicitly type SETs.
>  
> The specification is available at:
> https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-01
>  
> An HTML-formatted version is also available at:
> http://self-issued.info/docs/draft-sheffer-oauth-jwt-bcp-01.html
>  
>-- Mike
>  
> P.S.  This notice was also posted at http://self-issued.info/?p=1714 and as 
> @selfissued.
> ___
> 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] Call for Adoption: JSON Web Token Best Current Practices

[Phil Hunt (IDM)]

+1 adoption

Phil

> On Jul 20, 2017, at 11:26 AM, John Bradley  wrote:
> 
> I support adoption
> 
>> On Jul 20, 2017, at 2:37 PM, Rifaat Shekh-Yusef  
>> wrote:
>> 
>> All,
>> 
>> We would like to get a confirmation on the mailing list for the adoption of 
>> the JSON Web Token Best Current Practices as a WG document
>> https://datatracker.ietf.org/doc/draft-sheffer-oauth-jwt-bcp/
>> 
>> Please, let us know if you support or object to the adoption of this 
>> document.
>> 
>> Regards,
>>  Rifaat
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Short lived access token and no refresh token

[Phil Hunt (IDM)]

In OAuth, the audience for the token is the resource server and not the client. 
OAuth delegates a client to act for a user. OIDC issues an ID token whose 
audience is the client. 

Assuming OAuth...

The life of the token is dependent on the risk at the resource. 

Refresh token lets the client do a proof of possession authentication test to 
ensure confidence when user not necessarily present. 

Re-authorize forces the user context in browser to be reverified. 

Note that many implementations at this stage just re-evaluate cookie state to 
determine if SSO and grant state is still valid and either authorization is 
regranted or user is re-authenticated etc. 

As John mentions, OIDC layers on additional features since it role is user 
authen for the client rather than delegation to the client. 

Phil

> On Jul 25, 2017, at 9:47 AM, CARLIER Bertrand 
>  wrote:
> 
> Hello,
>  
> Depending on what is meant by “scenario to be supported from the 
> authorization server (platform) itself and not in the client app or resource 
> server”, it may be it difficult (or impossible) to achieve.
> In the end, the resource server only applies token lifetime policy *if it 
> decides to do so*, whatever the AS kindly asked him to do
>  
> --
> Bertrand CARLIER
> 
>  
> De : OAuth [mailto:oauth-boun...@ietf.org] De la part de John Bradley
> Envoyé : mardi 25 juillet 2017 18:03
> À : Bill Burke 
> Cc : oauth@ietf.org
> Objet : Re: [OAUTH-WG] Short lived access token and no refresh token
>  
> Max-age has to do with user re-auth in connect.
>  
> Some AS only give refresh tokens if a scope of offline_acess or some such 
> special scope is requested.
> There is no standard scope for that.
>  
> I don’t know of any way for the client to control the lifetime of the access 
> token other than by revoking it with the AS.
> https://tools.ietf.org/html/rfc7009
>  
> Depending on the AS you should be able to control the AT lifetime on a per 
> client basis.
>  
> John B.
>  
> On Jul 25, 2017, at 11:37 AM, Bill Burke  wrote:
>  
> For browser apps, implicit flow provides an access token but no refresh 
> token.  For non-browser apps only client credentials grant doesn't supply a 
> refresh token.  As for token access times, I believe only extensions to OAuth 
> define those types of capabilities.  i.e. OpenID Connect defines a "max-age" 
> claim that you can pass when requesting a token.
>  
> On 7/25/17 10:48 AM, Saurav Sarkar wrote:
> Hi All,
>  
> We have a scenario where one of our stakeholder wants to mandatorily initiate 
> the authentication at certain point of time.
>  
> As per 
> https://www.oauth.com/oauth2-servers/access-tokens/access-token-lifetime/
> there can be an option where access token is set for certain time and refresh 
> token is not set. So we want to explore this option for this scenario.
>  
> I have couple of questions regarding this
>  
> (a) Is this  option part of OAuth 2 specification ? If yes can you please 
> point me to the exact IETF link ?
>  
> (b) Is there any other way our scenario can be achieved ? We want this 
> scenario to be supported from the authorization server (platform) itself and 
> not in the client app or resource server.
>  
> Thanks and Best Regards,
> Saurav
> 
> 
> 
> ___
> 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
>  
> The information transmitted in the present email including the attachment is 
> intended only for the person to whom or entity to which it is addressed and 
> may contain confidential and/or privileged material. Any review, 
> retransmission, dissemination or other use of, or taking of any action in 
> reliance upon this information by persons or entities other than the intended 
> recipient is prohibited. If you received this in error, please contact the 
> sender and delete all copies of the material. 
> 
> Ce message et toutes les pièces qui y sont éventuellement jointes sont 
> confidentiels et transmis à l'intention exclusive de son destinataire. Toute 
> modification, édition, utilisation ou diffusion par toute personne ou entité 
> autre que le destinataire est interdite. Si vous avez reçu ce message par 
> erreur, nous vous remercions de nous en informer immédiatement et de le 
> supprimer ainsi que les pièces qui y sont éventuellement jointes.
> ___
> 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] Recommendations for browser-based apps

[Phil Hunt (IDM)]

Except a refresh token is not purely bearer. The client is required to 
authenticate to use it. 

Phil

> On Sep 19, 2017, at 2:33 PM, Bill Burke  wrote:
> 
> I'd be curious to the response to this too.
> 
> Seems to me that refresh token has the same possible security risks in
> an Angular app as an access token, except the refresh token is valid
> longerStill, if you did the implicit flow, you'd have to have
> longer access token timeouts as it would be really annoying for the
> user to have to login again and again in a long session with your
> Angular app.
> 
> We have a javascript adapter that does Authz Code Flow with PKCE for
> our Angular app.  It also does CORS checks on the code to token XHR
> request just in case on the IDP side.
> 
>> On Tue, Sep 19, 2017 at 9:27 AM, Stefan Büringer  
>> wrote:
>> Hi,
>> 
>> there were some discussions in January regarding recommendations for
>> browser-based apps
>> (https://www.ietf.org/mail-archive/web/oauth/current/msg16874.html).
>> 
>> I'd just like to ask if the Authorization Code Flow with PKCE is a valid
>> option for Single-Page-Applications (in our case Angular), because Implicit
>> Flow cannot be used in our scenario.
>> 
>> Authorization Code Flow with PKCE eliminates the necessity for client
>> secrets, but our concern is that exposing the refresh token to the SPA might
>> be a security risk, compared to the Implicit Flow were no refresh token is
>> exposed.
>> 
>> What's your take on this?
>> 
>> Kind regards,
>> Stefan Büringer
>> 
>> P.S. I couldn't find that much on the internet regarding Authorization Code
>> Flow with PKCE in SPAs, if you have some recommendations for good blog posts
>> I would be grateful.
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
> 
> 
> 
> -- 
> Bill Burke
> Red Hat
> 
> ___
> 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