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

[Vladimir Dzhuvinov <[e-mail]>]

Comment starts at line 173 :)

On 22/02/16 14:08, John Bradley wrote:
> Inline
>
>> On Feb 22, 2016, at 9:22 AM, Nat Sakimura <[e-mail]> wrote:
>>
>> [case1] Code phishing + cut-n-paste attack  <>
>>   [case1a] through BadAS to GoodAS redirect
>>   [case1b] through tampering the unprotected client access response
>>   [case1c] through the server log
>> [case2] Token phishing (in case of implicit flow). 
>> [case3] Code and Client credential phishing
>>  
>> All of these seem to involve the tampering of the unprotected communication. 
>> If we can secure all the communication, the problem would be solved for all the variants and for those that we still do not know. One way of doing it is to use OAuth JAR and authorization response that includes ID Token, but that’s not possible in many cases as I understand. 
>> We have to accommodate a measure that is proportionate to the risks. 
>>  
>> The risk impact of [case1] is that the code is stolen, and it is used against the client to “login” to the client. The attacker will not have an access to the access token. Is that right? If that is the case, is this a case that we are really concerned of? Is it not out of scope for OAuth? If so, we can punt this case to something like a login protocol such as OpenID Connect. It also has the notion of “issuer” baked in, so there will be less conflict to use the mix-up draft. 
> In this case with OAuth the information protected by the AT can still be stolen.  While the attacker doesn’t get the AT directly it gets control of a client that has the AT.   If I link my Flikr account to your private Flikr feed, you as the Resource owner is still compromised.   Arguing that OAuth didn’t leak the token is not a good argument.   OAuth needs to protect against this.
>
>>  
>> The risk impact of [case2] is more OAuth specific. The token is stolen as the token is going to be sent to a rogue resource, and the resource can use that to obtain the resource that was supposed to be only available to the proper client. 
>>  
>> The risk impact of [case3] is the most grave among these three. Now the attacker can create his own client that impersonates the compromised client. 
>>  
>> OAuth-mix-up
>> ---------------------------
>> OAuth-mix-up draft gives one way of addressing [case2] by introducing a new concept of “issuer” and “discovery” to RFC6749. It also returns client_id and verifies it in 4.2, but if the BadAS has assigned a same client_id to the client, it does not help. 
> Client_id are not guaranteed to be unique.  They need to be name spaced by the AS.   In OAuth currently we have no name for the AS this makes that difficult, the client can use the authorization endpoint URI, but that logic may well break in multi tenant situations.   Having a clear issuer string makes it easier for the client.  
>>  
>> By comparing the issuer stored in the session (the draft should be explicit about it) with the issuer in the response, the client can find out that the party he is getting the response from is not the one he sent a request to, that communication was compromised/tampered with, provided that the response is not tampered by the attacker in-browser. 
> Yes
>>  
>> Note that the response may still be tampered (e.g., by MITB) so that the issuer can be re-written, in which case the mitigation does not work, but IMHO, we do not have to worry about it here, as with MITB, you can do worse things easier. 
> Yes
>>  
>> One of the issue with this approach is that the central notion of “issuer” is new to the existing servers and clients. The verification rule in 4.1 states “Compare the issuer URL for the authorization server that the client received when it registered at the authorization server”, but in most existing pure OAuth cases, there is no such thing, so you cannot compare. This means that you would have to re-register, and if you are doing that, the per-AS redirect_uri seems to be a much simpler solution. 
> The client developers I have talked to really hate per AS redirect URI as being too awkward for deployments.  
>
> The client would not need to re register to add a issuer URI to its client_id record.   That is one of the ways to do it.
>>  
>> Also note that this is not a general framework for finding out tainted communication, so it may have other holes. 
>>  
>> OAuth-meta
>> -------------------
>> OAuth-meta is not designed as a specific fix to the problem. Rather, it was designed as a general framework of providing the meta-data to the responses by leveraging RFC5988 registry. It just happens to mitigate this particular case. 
>>  
>> Again, it is not a general framework for finding out tainted communication, so it may have other holes. 
> Without sending the resource in the request, the Authorization endpoint, and token endpoints are not necessarily going to be able to return the correct next hop.
>
> My biggest concern is that this potentially moves some of the client logic into the AS.   I don’t know that that is a bad thing but it feels to me like a real change to OAuth as it currently is.   I think we need to really think about this change, and how it will impact OAuth overall.  
>
> I see this as potentially complimentary OAuth mix up returning a logical name for the AS.
>
>>  
>> Per AS Redirect URI
>> --------------------------------
>> This does not involve wire protocol changes. It just adds requirements on the redirect uri. This by far is the simplest solution for [case2] (and [case1]), IMHO. 
>>  
>> Again, it is not a general framework for finding out tainted communication, so it may have other holes.
> This is probably the hardest for the client developer and for the deployer.  Yes it is simplest from a spec point of view. 
> We need more developer feedback on this.
>
>>  
>> (Extended) PKCE
>> ---------------------------------
>> To begin with, it works only with code flow. There has to be something else to deal with implicit flow. 
>>  
>> PKCE binds the authorization request/response to the token request. 
>> If used with a confidential client, it seems to mitigate the vulnerability. 
>> John points out that it is not the case. I must be missing something here… but my logic goes like: 
>>  
>>  
>> 1.     The good client creates code_challenge-v and code_verifier-v=S256(code_challenge-v) and sends the client_id-v + code_challenge-v + state to the BadAS Authz EP. 
>> 2.     BadAS as a client prepares a code_verifier-b and code_challenge-b=S256(code_verifer-b). 
>> 3.     BadAS redirects to GoodAS with the client_id-v + code_challenge-b + state-v.  
>> 4.     GoodAS stores the code_challenge-b. 
>> 5.     GoodAS returns code-v + state-v to the client’s redirect uri. 
>> 6.     The client finds the AS from the state and sends code-v + code_verifier-v + secret-b to the BadAS token endpoint. Now, code-v and code_verifer-v is phished. 
>>  
>> Now the attacker tries to use the code-v and code_verifier-v. 
>>  
>> ### Case A:
>> 7.     The BadAS as a client sends client_id-v + … but he does not have client secret for the good client, so it fails. 
>>  
>> ### Case B: 
>> 8.     The BadAS as a client sends client_id-b + code-v + code_verifier-b + secret-b etc. to GoodAS. 
>> 9.     GoodAS verifies the code_verifier-b is associated with code-v, but that code-v is not associated with client_id-b, so the token request fails. 
>>  
>> ### Case C: cut-n-paste
>> 10.  The attacker launches cut-n-paste attack by replacing the code-b with code-v. 
>> 11.  The verifiers does not match, so fails. 
>>  
>> Please let me know what I am missing. 
> In a step 0 the attacker has the good client create another request in the attackers user agent to get state-0 and code_challange-0
>
> Step 2 is not required.
> Step 3 Bad AS redirects to good AS with client_id_v + state-v + code_challenge-0
> Step 4 GoodAS stores code_challenge-0
> Step 5 GoodAS returns code-v + state-v to the clients redirect_uri
> Step 6 The client finds the AS from the state and sends code-v + code_verifier-v + secret-b to the BadAS token endpoint. Now, code-v and code_verifer-v is phished. 
>
> Case C1 :  cut and paste
> 10.  The attacker launches cut-n-paste attack by inserting code-v into a response using state-0
> 11. The client sends code-v and based on state-0 it sends code_verifyer-0 to the good AS token endpoint.
> 12. The GoodAS verifies that code-verifyer-0 is correct for code_challange-0 that it bound to code in step 4
> 13. The GoodAS receives RT + AT.
> 14. The attacker has now used the client to bind the users resource to it’s account and is transferring money or looking at your data.
>
> This could be 3rd party financial app like Mint as an example or photos or any other PII that could then be used to escalate identity theft.
>
> This variation of the attack combining cut and paste with confused client was not mentioned in the research papers.
>
> I found it looking to see if PKCE could be used to mitigate the confused client attack.
>
> As I mentioned in a response to William, while the current PKCE Challenge methods only make the attack harder by forcing the attacker to get the client to make a step 0 request to get a code_challenge to use in the request,  we could define a new challenge method that would be effective.
>
> That would remove the need to have a separate mechanism to prevent cut and paste.
>
> The problem is that the PKCE challenge is independent of state so becomes vulnerable to the confused client.
>
> What we would need to do is include state in the challenge so that if the AS receives mismatched state and code_challange in step 3 the verification of code verifier will fail. Effectively combining the cut and paste mitigation with PKCE.
>
> I haven’t had time to write this up, but if the code_challenge == SHA256 (SHA256(state) || token_endpoint URI || Authorization_endpoint URI || client_id || code-veriyer) ,  then the attacker could not change state, client_id, or token_endpoint  independently of code_challenge.  (note I am using a hash of state to make storage size deterministic for the AS on the grounds that the client already needs to be able to do the hash) (Some attacks  change the client_id in the request so I am including it in the hash)
>
> This is slightly more complicated than than S256, but not that much.  I wish I had thought of this when we were doing PKCE.   Hit me with the stupid stick, my fault.
>
> I don’t know if it stops all the confused client attacks though.
>
> If the client is confidential then it gives up it’s client secret assuming compromised registration, so we can’t really count on that for symmetric client authentication.
>
> By including the token endpoint in the comparison if the client is sending the code to the attacker the client will use a different token endpoint_uri in to calculate the code_challenge than the GoodAS will use to verify it.    This would stop both cut and paste as well as stopping the attacker from using the code if they get it.   The attacker can’t get Secret for state-0, so it can’t create code_challenge that would be valid.
>
> This stops the registration attack where the client gets a bad AS discovery endpoint that has all the Good AS info including dynamic registration endpoint but the bad AS token endpoint.   The bad AS would get the token, client_secret and code_verier, but will fail pkce verification because the token endpoint will be wrong.
>
> The attack where the client registers with the good AS but with bad token endpoint and Authorization endpoint gives the attacker the ability to change the code_challenge that the Good AS is going to see.   It would need to make a new challenge using state and the GoodAS token endpoint and it’s client_id.   
> To do that it needs the code_verifier to use to calculate the hash to use as the code_challenge value.  As long as the client is not tricked into accepting a replay of the authentication response we should be safe.  The client would need to do replay protection on the code_verifier values before it makes a request to the token endpoint.  
>
> The BadAS could however make up a new code_challenge and code_verifier and use that in the request. For this one the AS would need to do pull discovery on the client to get a key, or the AS needs to return something in the response.  This attack can completely proxy all the endpoints as far as the client is concerned and is taking advantage of the AS saying you are granting permission to site X based on the redirect URI.  
>
> I can’t see PKCE on it’s own being able to stop a client from being used as a redirector back to the attacker unless you also returned the code_challenge in the response from the authorization endpoint.
>
> Hypothetically if we returned code_challenge in the response from the authorization endpoint and have a new PKCE challenge method we might find it covers all of the attacks.
>
> We would need to put some serious analysis into this to see if it really covers all the attacks. 
>
> It however doesn’t address the “token” response_type or steeling the access token by impersonating the RS. 
>
> I think the correct way to stop the problem with access tokens is by audience restricting them.  
> To do that the client needs to provide an audience in it’s request and the AS needs to include that in the AT.
>
> I included the Authorization_endpoint URI in the hash to detect if the auth request may have been tampered with to change the audience for the AT.
>
> For implicit we could have a version of PKCE where the AS returns a parameter with S256( client_id || authorization_endpoint URI || resource endpoint URI) to verify the request was not tampered with, and that would allow the AT to be properly audience restricted. 
>
>
> This would be a completely new approach not involving discovery, logical names for AS, or link relations.
>
> Effectively this code_challenge method becomes a signature over parts of the request and the implicit audience of the token_endpoint URI.  
>
> People keep asking why PKCE doesn’t stop these attacks, and it won’t with the current PKCE methods,  however a new method along the lines I sketched out may let it work, or I could be completely wrong.
>
> Too bad I don’t think I will make RSA to go over this in person.
>

If PKCE with a new mode manages to fix everything, that would be great!

I'm just reframing the essence of the proposed solution, as I roughly
understood it:

1. The mix-up attack causes the client to be set up with compromised
endpoints. There are 3 ways to prevent that:

a) by letting the client submit a signature of the setup endpoints to
the AS, via new PKCE mode, or version of PKCE for implicit.
b) by letting each AS response hint the URL for the next hop
c) by a combination of a & b

=> a) is best because it's just one extra param, the hash is of fixed
size and relatively short



2. The confusion attack is made possible when using more than one AS.
There are 3 ways to prevent that:

a) by requiring separate redirect_uri for each AS
b) by returning the client_id in the AS response


b) is best because it can be combined with the mix-up attack prevention
via new PKCE mode.



If multiple resource URIs are to be included in the hash, how do we make
the order predictable?


Vladimir


> John B.
>
>
>
>>  
>> 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:[e-mail]] On Behalf Of John Bradley
>> Sent: Saturday, February 20, 2016 9:16 PM
>> To: William Denniss
>> Cc: [e-mail]
>> Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption
>>  
>> Inline
>>> On Feb 20, 2016, at 9:49 AM, William Denniss <[e-mail]> wrote:
>>>  
>>> Maybe it's because I wasn't at the Darmstadt meeting so I don't have the full context, but I don't find draft A to be all that clear. Here's my review feedback:
>>>  
>>> Regarding the text "a client may be confused simply because it is receiving authorization responses from more than one authorization server at the same redirection endpoint". Even if the client re-uses the same redirection endpoint, shouldn't state solve this? All incoming responses should have an outgoing request with a matching state that would identify the authorization request and therefore authorization server.
>>  
>> If only that were the case.   That is the nub of the problem people think state works to do that, but it enables the attack not stops it.
>>  
>> State contains where the client sends the request.   The client assumes any response following that is from the AS it sent the request to.  
>> Most of the attacks documented take advantage of this by misdirecting the request to a different AS than the one the client “thinks” it is making the request to.  
>>  
>> This is done in two ways. One is by pointing at another AS’s authorization endpoint as part of registration, and the other is by redirecting and rewriting the authorization request.
>>  
>> The client thinking it has a response from a AS based on state then uses the associated token and RS endpoints.   Those endpoints are wrong for the AS that really returned the response.   Thus the client becomes a proxy for relaying responses from the target AS.
>>  
>> Both mitigations attempt to mitigate this by having the AS return something that can be compared with state to determine if the request has been misdirected.
>>  
>> In one case we return a logical identifier (Name) for the AS that is compared to a name provided as part of client setup.  This name can optionally be used as the input to discovery to verify other meta-data about the AS.
>>  
>> In the second mitigation the URI of the token endpoint or resource server is returned.
>>  
>> They both provide a way for the client to determine if the stored state is invalid because the response is coming from a different place than the request went to.
>>  
>> It was noted by the researchers that the OIDC flow “code id_token” was not susceptible to this attack because the client validates the issuer of the id_token and the client_id that the AS thinks it is responding to (some of the attacks rewrite the client_id in the request).
>>  
>> For reference http://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation points 2 & 3 of the OIDC validation.
>>  
>> Knowing that works based on researcher feedback, the first option allows the two id_token claims to be returned from the Authorization endpoint without forcing OAuth clients to support signed JWT.   It also allows AS to provide a issuer URI but allows clients to compare the strings without forcing them to do discovery.   Clients that do discovery can use this value to bootstrap/validate that.   This takes advantage of validation that some clients already perform and applies it to the code response.
>>  
>> The second option from Nat allows the client to compare the token_endpoint URI from configuration to the one in the response.  A difference would indicate that the AS is different, in a similar way to the other option.  
>>  
>> The difference is that the second option doesn’t include the client_id and while I don’t have an attack against that off the top of my head, it was felt that it is a open attack surface and should be closed.  
>>  
>> The other difference is I think more subtle and changes OAuth in the second option (Nat probably argues that would be a good thing).
>> OAuth to this point assumes that the client is in charge, that the developer configures the endpoints etc via service documentation.
>> In the authorization request or the AT request the AS has no information about what RS is being used as part of the protocol.
>>  
>> The second option changes that by providing link relationships where each step provides meta data about where to use the result.
>> The Authorization endpoint points to the token endpoint, the token endpoint points to the resource server and the resource server points to the Authorization endpoint.   To get that to work for a number of uses cases you probably need to tell the authorization endpoint and possibly the token endpoint what resource or resources you want the scopes for.    A given AS might have more than one token endpoint (not common but not precluded,  but something that might happen in multi tenant or other special cases), and if it is using JWT access tokens it may not even know about the given RS.
>>  
>> So to be able to give the meta-data for the next hop the endpoint responding may need more information.
>>  
>> The two mitigations are not incompatible, we could do both.
>>  
>> I do however think that the second one may have architectural side effects that we need to more fully discuss.  
>> Adding link relation/follow your nose processing to OAuth may be a good thing, but may have impacts that we have not fully thought through yet.
>>  
>>>  
>>>  
>>> For the issue of dynamic discovery and the potential to insert a malicious discovery document: can the recommendation be to use the hybrid flow of Connect if you do discovery (and validate the issuer before exchanging the code)?  Do we need to invent something new for this use-case?
>>  
>> As above this would work , but we don;t want to force all OAuth clients to have to deal with JWT.   This would be a fix for Connect if we were only concerned about that.
>>
>>
>>>  
>>> Regarding sections 5 & 6 ("Mitigation Data Sent to the Token Endpoint"), this describes something that seems similar to what is achieved by PKCE (RFC7636). Binding information to the authorization code that must be presented to redeem the code is precisely what PKCE does, and PKCE has additional security properties. With the PKCE S256 challenge method, the authorization request and response can leak in their entirety, and yet still the attacker couldn't exchange the authorization code. Let's just recommend RFC7636 for this mitigation.
>>>  
>> Unfortunately PKCE makes the assumption that attacker cannot modify the request.  In this case the attacker can modify the request. 
>>  
>> PKCE provides protection in cases where the attacker can’t modify the PKCE challenge in the request. 
>> If the attacker can modify the request then they make a new request in a second browser to get the PKCE challenge and replace the one in the request being modified by that one.
>>  
>> I need to think about it a bit more but there might be a way to do it by defining a new PKCE method. 
>>  
>> If the code_challenge  were a HASH of state || code_verifyer, that would do both.   
>>  
>> The server would need to store state and code_challange.  The client would just calculate the hash over both, but still send the same code_verifier.
>> ( optimization would be for the code_challange == S256 (S256(state) || code_verifier)  that way the AS only needs to store the hash of state)
>>  
>> The attacker can’t change the state in the first request, or the client will reject the response, and because the code_verifyer will be different between the requests the AS would reject the second one because the code_challange will be wrong.
>>  
>> That is more complicated for the client, but would allow you to do it with PKCE with no more crypto than PKCE S256 (the MTI) already requires.
>>  
>> For Asymmetric PKCE the code_challange would be a JWK of the public key and the code_verifier would be a JWS (S256(state) )
>> (You might want to include code in the JWT but I need to think that through)
>>  
>> So yes unless someone finds a flaw in that logic we may be able to define some PKCE modes to mitigate against cut and paste.
>> I didn’t think of defining a new PKCE mode at the time.  You should have been at the meeting:)
>>  
>>
>>
>>> The security researcher documents are only informative references, and yet the spec seems to rely on them normatively. E.g.:
>>> *  "Mitigating the attacks also relies on the client sending additional data about the interaction to the token endpoint" (how does this mitigate the attacks? and what attack exactly?).
>>> *  "a client may be confused simply because it is receiving authorization responses from more than one authorization server"  (why is the client confused?)
>>> I would like to see the attacks normatively described in the spec.
>>>  
>>> For my own knowledge: what are some of the use-cases that are subject to these attacks? I'm not convinced every RP that talks to more than 1 AS is at risk today. What are some risky situations that exist which are mitigated by this draft?
>>  
>> Any RP is at risk if one of the AS it talks to is compromised, it can compromise all of the AS that the client talks to.  That is just not a good design.
>>  
>> Hans did a proof of concept that only required access to the logs of one AS to compromise all AS.
>>  
>> John B.
>>>  
>>>  
>>>  
>>> On Fri, Feb 19, 2016 at 9:12 PM, Phil Hunt (IDM) <[e-mail]> wrote:
>>>> Option A
>>>>
>>>> Phil
>>>>
>>>>> On Feb 19, 2016, at 13:39, Hans Zandbelt <[e-mail]> 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:[e-mail]] On Behalf Of Hannes Tschofenig
>>>>>> Sent: Friday, February 19, 2016 11:43 AM
>>>>>> To: [e-mail]
>>>>>> 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
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>> --
>>>>> Hans Zandbelt              | Sr. Technical Architect
>>>>> [e-mail] | Ping Identity
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>  
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth