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

From: Brian Campbell <[email-masked]>
Date: Tue, 12 Jan 2016 15:24:04 -0700

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
<https://mailarchive.ietf.org/arch/msg/oauth/JIVxFBGsJBVtm7ljwJhPUm3Fr-w>)
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
<http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00>
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.

---

From: Mike Jones <[email-masked]>
Date: Tue, 12 Jan 2016 22:53:24 +0000

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<mailto:[email-masked]>
Sent: ‎1/‎12/‎2016 5:24 PM
To: oauth<mailto:[email-masked]>
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<https://mailarchive.ietf.org/arch/msg/oauth/JIVxFBGsJBVtm7ljwJhPUm3Fr-w>) 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<http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00> 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.

---

From: Justin Richer <[email-masked]>
Date: Tue, 12 Jan 2016 23:03:08 -0500

+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 <[email-masked]> wrote:
> 
> From: Brian Campbell <mailto:[email-masked]>
> To: oauth <mailto:[email-masked]>
> 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 <https://mailarchive.ietf.org/arch/msg/oauth/JIVxFBGsJBVtm7ljwJhPUm3Fr-w>) 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 <http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00> 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. 
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Tue, 12 Jan 2016 20:31:46 -0800

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 <[email-masked]> wrote:
> 
>> From: Brian Campbell
>> To: oauth
>> 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. 
>>

---

From: [email-masked]
Date: Wed, 13 Jan 2016 10:52:38 +0100

I fully agree with Brian. We came up with a rather simple (== w/o
crypto) solution to mitigate the mix-up attack. We should first specify
them as discussed and then have a discussion in the working group - also
about additional attack vectors. 

As discussed in Darmstadt, we should also come up with a comprehensive
description of the threats arising from the more dynamic way OAuth is
used meanwhile. I hope the researches will support this effort. 

kind regards,
Torsten. 

Am 13.01.2016 05:31, schrieb Phil Hunt (IDM): 

> +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 
> 
> -------------------------
> From: Brian Campbell
> 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 [1]) 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 [2] 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. 
> 
> https://www.ietf.org/mailman/listinfo/oauth [3]

> https://www.ietf.org/mailman/listinfo/oauth [3]

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth [3]

Links:
------
[1]
https://mailarchive.ietf.org/arch/msg/oauth/JIVxFBGsJBVtm7ljwJhPUm3Fr-w
[2] http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00
[3] https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Campbell <[email-masked]>
Date: Wed, 13 Jan 2016 06:55:05 -0700

Thanks Mike (and reluctantly John, I guess). I'm pleased to hear about the
direction things are taking and look forward to reviewing -01.

On Tue, Jan 12, 2016 at 3:53 PM, Mike Jones <[email-masked]>
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.
>
> ------------------------------
> From: Brian Campbell <[email-masked]>
> To: oauth <[email-masked]>
> 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

---

From: Bill Mills <[email-masked]>
Date: Wed, 13 Jan 2016 19:36:48 +0000 (UTC)

Maybe this has been covered elsewhere, but one can see the case where "iss" in an example is set to "my_auth_server" and that cut/paste gets re-used.   That's also possible even in the OpenID Discovery mechanism, it requires the implementer to actually pick a unique value.  It would be better if this were not dependent on by-hand configuration.
-bill 

    On Tuesday, January 12, 2016 8:03 PM, Justin Richer <[email-masked]> wrote:

Best wishes,
-- MikeFrom:Brian Campbell
Sent:‎1/‎12/‎2016 5:24 PM
To:oauth
Subject:[OAUTH-WG] Mix-Up About The Mix-Up Mitigation

To the best of my recollection the general consensus coming out of the meetings in Darmstadt (which Hannes mentioned inOAuth 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.

---

From: Antonio Sanso <[email-masked]>
Date: Thu, 14 Jan 2016 12:13:52 +0000

hi,

same here. I have the same recollection of the meeting in Darmstadt as Brian. I do appreciate the draft of Mike (kudos to him) and his will to steer toward the consensus.

regards

antonio

On Jan 13, 2016, at 5:31 AM, Phil Hunt (IDM) <[email-masked]<mailto:[email-masked]>> wrote:

Phil

On Jan 12, 2016, at 20:03, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

 — Justin

On Jan 12, 2016, at 5:53 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

Best wishes,
-- Mike

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 15 Jan 2016 10:34:37 +0000

Hi All,

I'm reviewing RFC 7622 as we are going ahead with implementing it.
I have a question:

1. Token Hint in the introspection request.
The spec mentions 'refresh_token' as one of the possible values. But a 
protected resource does not see a refresh token (ever ?), it is Access 
Token service which does.
When would a protected resource use a 'refresh_token' hint when 
requesting an introspection response ?

Thanks, Sergey

---

From: John Bradley <[email-masked]>
Date: Fri, 15 Jan 2016 08:32:33 -0500

Some people wanted the client to be able to use introspection.

The ability to pass a refresh token is a legacy of that.    A RS would never have a refresh token unless it is acting as a client.  That is correct.

John B.

> On Jan 15, 2016, at 5:34 AM, Sergey Beryozkin <[email-masked]> wrote:
> 
> Hi All,
> 
> The spec mentions 'refresh_token' as one of the possible values. But a protected resource does not see a refresh token (ever ?), it is Access Token service which does.
> When would a protected resource use a 'refresh_token' hint when requesting an introspection response ?
> 
> Thanks, Sergey
> 
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 15 Jan 2016 13:47:49 +0000

Hi John

Thanks, looks like it was a last minute change because Introduction does 
not explain why would clients want to use the introspection endpoint to 
effectively 'unwrap' the opaque token representations.

I have another question. How to report the expiry time in cases when the 
tokens do not expire ? I'm aware of some deployments where access tokens 
are only manually deleted and otherwise would not expire.

Perhaps not reporting the expiry time is equivalent to the token never 
expiring ? Or may be reporting 0 or -1 works ?

Thanks, Sergey

---

From: Buhake Sindi <[email-masked]>
Date: Fri, 15 Jan 2016 16:13:04 +0200

Hi,

Are you not mistaking this with RFC 7662? :-)

Kind Regards,

Buhake Sindi

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 15 Jan 2016 14:15:01 +0000

Ouch, you are right, sorry for the confusion,
Thanks, Sergey
On 15/01/16 14:13, Buhake Sindi wrote:
> On 15 Jan 2016 12:34, "Sergey Beryozkin" <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi All,
>
>     The spec mentions 'refresh_token' as one of the possible values. But
>     a protected resource does not see a refresh token (ever ?), it is
>     Access Token service which does.
>     [email-masked] <mailto:[email-masked]>

-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

---

From: Buhake Sindi <[email-masked]>
Date: Fri, 15 Jan 2016 16:21:00 +0200

Hi,

Was just reading the specification (RFC 7662) and the following link
"breaks"

Chapter 2.3

2.3 <https://tools.ietf.org/html/rfc7662#section-2.3>.  Error Response

   If the protected resource uses OAuth 2.0 client credentials to
   authenticate to the introspection endpoint and its credentials are
   invalid, the authorization server responds with an HTTP 401
   (Unauthorized) as described in Section 5.2
<https://tools.ietf.org/html/rfc7662#section-5.2> of OAuth 2.0
[RFC6749 <https://tools.ietf.org/html/rfc6749>].

Richer                       Standards Track                    [Page 8]

  <https://tools.ietf.org/html/rfc7662#page-9>RFC 7662
<https://tools.ietf.org/html/rfc7662>                   OAuth
Introspection              October 2015

   If the protected resource uses an OAuth 2.0 bearer token to authorize
   its call to the introspection endpoint and the token used for
   authorization does not contain sufficient privileges or is otherwise
   invalid for this request, the authorization server responds with an
   HTTP 401 code as described in Section 3
<https://tools.ietf.org/html/rfc7662#section-3> of OAuth 2.0 Bearer
Token
   Usage [RFC6750 <https://tools.ietf.org/html/rfc6750>].

The link of [Section 5.2] and [Section 3] both points to the same link
(of RFC 7662) instead of the specified RFC. E.g. There is no Section
5.2 on RFC 7662 but the link points to it.

Kind Regards,

Buhake Sindi

---

From: John Bradley <[email-masked]>
Date: Fri, 15 Jan 2016 09:44:34 -0500

Currently the canonical form of RFC is ASCII and there is a external tool that tries to do HTML markup on the ascii version.

When authoring something that works in english may well not get the right HTML markup.
The Authors do there best but there is no way to fix by editing the HTML as a reasonable person might expect.

The process is changing to make the XML the canonical form so that HTML can be produced with correct markup.

Going forward I hope these markup problems are eliminated in new drafts.

John B.

> On Jan 15, 2016, at 9:21 AM, Buhake Sindi <[email-masked]> wrote:
> 
> Hi,
> 
> Was just reading the specification (RFC 7662) and the following link "breaks"
> 
> Chapter 2.3
> 
> 
>    (Unauthorized) as described in Section 5.2 <https://tools.ietf.org/html/rfc7662#section-5.2> of OAuth 2.0 [RFC6749 <https://tools.ietf.org/html/rfc6749>].
> 
> 
> 
> 
> 
>   <https://tools.ietf.org/html/rfc7662#page-9>
> RFC 7662 <https://tools.ietf.org/html/rfc7662>                   OAuth Introspection              October 2015
> 
> 
>    HTTP 401 code as described in Section 3 <https://tools.ietf.org/html/rfc7662#section-3> of OAuth 2.0 Bearer Token
> The link of [Section 5.2] and [Section 3] both points to the same link (of RFC 7662) instead of the specified RFC. E.g. There is no Section 5.2 on RFC 7662 but the link points to it.
> 
> 
> Kind Regards,
> 
> 
> Buhake Sindi
> 
> 
> On 15 January 2016 at 16:15, Sergey Beryozkin <[email-masked] <mailto:[email-masked]>> wrote:
> On 15 Jan 2016 12:34, "Sergey Beryozkin" <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> 
>     Hi All,
> 
>     [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>     https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> 
> 
> -- 
> Sergey Beryozkin
> 
> Talend Community Coders
> http://coders.talend.com/ <http://coders.talend.com/>
>

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Sat, 16 Jan 2016 18:02:45 +0200

On 15/01/16 15:47, Sergey Beryozkin wrote:
> Hi John
>
> Thanks, looks like it was a last minute change because Introduction
> does not explain why would clients want to use the introspection
> endpoint to effectively 'unwrap' the opaque token representations.
>
> I have another question. How to report the expiry time in cases when
> the tokens do not expire ? I'm aware of some deployments where access
> tokens are only manually deleted and otherwise would not expire.
>

The core OAuth 2.0 spec seems to imply the former:

http://tools.ietf.org/html/rfc6749#section-5.1

Using a zero or negative integer may not be a good idea, as clients may
just take the value as it is and add it to the current system time,
concluding that the token has expired :)

Cheers,

Vladimir

>> The ability to pass a refresh token is a legacy of that.    A RS
>> would never have a refresh token unless it is acting as a client. 
>> That is correct.
>>
>> John B.
>>

-- 
Vladimir Dzhuvinov

---

From: Justin Richer <[email-masked]>
Date: Sat, 16 Jan 2016 11:14:22 -0500

All the values in the token introspection response are optional, except for “active”. If you don’t have anything to say about a particular aspect of the token, or can’t say it to the software that’s asking, then you generally leave it out of the response.

 — Justin

> On Jan 16, 2016, at 11:02 AM, Vladimir Dzhuvinov <[email-masked]> wrote:
> 
> 
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Mon, 18 Jan 2016 16:43:29 +0000

Hi Justin

Sorry I did not copy to the list with my previous response...

That sounds convincing, I was about to suggest that AS may opt not to 
report the expiry time simply because it is an optional property, but I 
guess that would be just an argument for the sake of the argument :-), 
as I guess in practice AS will report the expiry time of the tokens that 
actually expire...

Many thanks, Sergey

On 18/01/16 16:28, Justin Richer wrote:
> If the AS doesn't include the expiration then that means that the RS
> doesn't know anything about the token expiring or not. This can be
> caused by:
>
>   1) The token never expiring from a timestamp (could still get revoked
> or expire after a number of uses)
>   2) The RS not being allowed to know if the token expires
>
> Either way, the RS doesn't know anything about the token expiring or not
> and so should treat it as if it hasn't expired since that's all the AS
> has told it. An RS trying to second guess the AS response here is going
> to get into trouble.
>
> If the token expires "shortly" then there would be an expiration in the
> response, if the RS is allowed to know that. There's no interoperability
> issue here, still, and a special value wouldn't fix this.
>
>   -- Justin
>
> On 1/18/2016 11:10 AM, Sergey Beryozkin wrote:
>> Hi
>>
>> If the only way for AS to indicate the token has expired is not to
>> report this value, while the other AS does not report the specific
>> expiry time simply because the expiry property is optional, then RS
>> working with both of those 2 AS has no way to understand if a given
>> token expires shortly or never expires at all.
>>
>> That is why I'm thinking having no special value indicating the token
>> does not expire is an interoperability issue (the communication
>> between RS and third-part AS servers)
>>
>> Thanks, Sergey
>> On 18/01/16 15:55, Justin Richer wrote:
>>> That's a problem for the RS to figure out in its logs system regardless
>>> of whether you choose a "special" value for non-expiration or not. I
>>> don't see how this changes interoperability.
>>>
>>>   -- Justin
>>>
>>> On 1/16/2016 4:50 PM, Sergey Beryozkin wrote:
>>>> Hi Justin
>>>> This is reasonable and it works with the introspection protocol
>>>> because the text says 'active' means AS must've checked the token has
>>>> not expired, but even so, it is in a 'conflict' with the
>>>> interoperability concept.
>>>> Consider a simple case where RS wants to log "Client uses access token
>>>> with this ID, the token expiry time - this time/never" and some other
>>>> RS wants to block the requests with the token which will expire in
>>>> less then say 5/10 secs.
>>>> When this RS works with one AS - this AS thinks it should not report
>>>> the expiry time because it means omitting it indicates the token never
>>>> expires. The other AS does not report it because: it either does not
>>>> know how to rep a 'never expires' value. The next AS thinks it is not
>>>> needed to be reported at all.
>>>> What should RS do willing to do the above tasks around the expiry time
>>>> do :-) ?
>>>>
>>>> Thanks, Sergey
>>>>
>>>> On 16/01/16 16:14, Justin Richer wrote:
>>>>> All the values in the token introspection response are optional,
>>>>> except for “active”. If you don’t have anything to say about a
>>>>> particular aspect of the token, or can’t say it to the software
>>>>> that’s asking, then you generally leave it out of the response.
>>>>>
>>>>>   — Justin
>>>>>
>>>>>>>>> On Jan 15, 2016, at 5:34 AM, Sergey Beryozkin
>>>>>>>>> <[email-masked]>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi All,
>>>>>>>>>

-- 
Sergey Beryozkin

Talend Community Coders

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 19 Jan 2016 11:03:32 +0000

Hi Justin

You mentioned a token expiry policy can be that this token will expire 
after a number of uses, in addition to a standard expiry time check.

Is there a standard mechanism to report to AS the token is being used 
(for the purpose of accessing RS resources) ?
I wonder if an actual token introspection request is sufficient to 
indicate to AS that the given token is being used right now to access RS 
- given that the actual client can now also introspect tokens without 
using them to invoke RS services.

is it up to AS Introspection endpoint to figure out the identity of the 
caller, example, if it knows it is RS then it will increase the usage 
count, if a client - won't ?

Thanks, Sergey

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 20 Jan 2016 10:25:55 +0000

Hi

Given that the draft-tschofenig-oauth-audience [1] has expired, I'm 
wondering if it is still relevant.

I know the token introspection response can provide the audience 
value(s), but the question is really how a client is associated with a a 
given audience in the first place. As such [1] may still make sense, for 
example, I can think of two options:
1. the client audiences are set out of band during the client 
registration time and all the tokens issued to that client will be 
restricted accordingly
2. the client is requesting a specific audience during the grant to 
token exchange as per [1]

I guess 1. is how it is done in practice or is 2. is also a valid option ?

Thanks, Sergey

[1] https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 20 Jan 2016 15:27:33 +0100

Hi Sergey,

that's a good question. After this document was published the
functionality had been integrated into the PoP solution document.
Recently, I got feedback that the functionality should be more generic
and it is independent of the PoP work.

So, I guess it is a good time to discuss the needed functionality and
where it should be included.

Ciao
Hannes

---

From: Roland Hedberg <[email-masked]>
Date: Wed, 13 Jan 2016 07:52:26 +0000

And I agree with Phil’s agreement with Brian :-)

I should also add that I during the last part of the meeting and on my flight home afterwards implemented the techniques I felt we had come to an agreement on at the meeting. That is the new authorization request response parameters iss and client_id as well as the use of state_hash at the token endpoint.

> 13 jan 2016 kl. 05:31 skrev Phil Hunt (IDM) <[email-masked]>:
>

---

From: Brian Campbell <[email-masked]>
Date: Wed, 20 Jan 2016 15:18:29 -0700

There does seem to be a need to provide the client a means of telling the
AS the place(s) and/or entity(s) where it intends to use the token it's
asking for. And that it's common enough to warrant it's own small spec.
This has come up several times before and I think has some consensus behind
doing it. What needs to happen to move forward?

The concept shows up in these three different drafts (that I know of
anyway):

https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00#section-3
has an audience parameter
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02#section-3
has an aud parameter
http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03#section-2.1
has both an audience and a resource resource

All the above apply only to the token request. However, there are ways of
requesting/obtaining access tokens that don't involve the token endpoint
<https://tools.ietf.org/html/rfc6749#section-4.2> so I think it follows
that  the same facility should be available for the authorization request
too.

---

From: Mike Jones <[email-masked]>
Date: Wed, 20 Jan 2016 22:25:35 +0000

As mentioned in Prague, Azure Active Directory uses a “resource” request parameter to supply the URL of the resource server that the access token is intended for.  However, I believe that Google uses scope values for this and some Microsoft services are moving towards using scope values as well.  Sorting this out soon would be good.

                                                                -- Mike

From: OAuth [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Wednesday, January 20, 2016 2:18 PM
To: Hannes Tschofenig
Cc: oauth
Subject: Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience

There does seem to be a need to provide the client a means of telling the AS the place(s) and/or entity(s) where it intends to use the token it's asking for. And that it's common enough to warrant it's own small spec. This has come up several times before and I think has some consensus behind doing it. What needs to happen to move forward?
The concept shows up in these three different drafts (that I know of anyway):

https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00#section-3 has an audience parameter
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02#section-3 has an aud parameter
http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03#section-2.1 has both an audience and a resource resource

All the above apply only to the token request. However, there are ways of requesting/obtaining access tokens that don't involve the token endpoint<https://tools.ietf.org/html/rfc6749#section-4.2> so I think it follows that  the same facility should be available for the authorization request too.

On Wed, Jan 20, 2016 at 7:27 AM, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
Hi Sergey,

Ciao
Hannes

---

From: John Bradley <[email-masked]>
Date: Wed, 20 Jan 2016 19:27:09 -0300

+1

> On Jan 20, 2016, at 7:25 PM, Mike Jones <[email-masked]> wrote:
> 
> From: OAuth [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Brian Campbell
> https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00#section-3 <https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00#section-3> has an audience parameter 
> https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02#section-3 <https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02#section-3> has an aud parameter 
> http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03#section-2.1 <http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03#section-2.1> has both an audience and a resource resource
> 
> All the above apply only to the token request. However, there are ways of requesting/obtaining access tokens that don't involve the token endpoint <https://tools.ietf.org/html/rfc6749#section-4.2> so I think it follows that  the same facility should be available for the authorization request too. 
> 
> 
> 
>  
> On Wed, Jan 20, 2016 at 7:27 AM, Hannes Tschofenig <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Sergey,
> 
> > [1] https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00 <https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00>
> >

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 20 Jan 2016 22:47:17 +0000

+1

Also, I have always thought that it would be good if one could ask for a
particular resource type, and the server could respond with the actual
location of it with the associated access token. This is because it is
often undesirable to tell the client the location of the resource before
the authorization from the privacy point of view.

So, the processing flow in this case will be:

   1. The client request an access to the resource type in the scope of the
   authorization request.
   2. The client request an access token to the resource type to the token
   endpoint with audience/resource/scope parameter.
   3. The token endpoint responds with token response with oauth-meta
   header indicating the URL of the resource as in
    draft-sakimura-oauth-meta.

Best,

Nat

2016年1月21日(木) 7:27 John Bradley <[email-masked]>:

> As mentioned in Prague, Azure Active Directory uses a “resource” request
> parameter to supply the URL of the resource server that the access token is
> intended for.  However, I believe that Google uses scope values for this
> and some Microsoft services are moving towards using scope values as well.
> Sorting this out soon would be good.
>
>                                                                 -- Mike
>
> *From:* OAuth [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Brian Campbell
> *Sent:* Wednesday, January 20, 2016 2:18 PM
> *To:* Hannes Tschofenig
> *Cc:* oauth
> *Subject:* Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience
>
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 20 Jan 2016 22:54:35 +0000

That doesn’t always work when there’s multiple resource servers that the authorization server could authorize access to.  Whereas, the client does know what it’s trying to access, or it wouldn’t be making the authorization request in the first place.  It’s fine for the client to tell the server what it wants access to.

                                                                -- Mike

From: Nat Sakimura [mailto:[email-masked]]
Sent: Wednesday, January 20, 2016 2:47 PM
To: John Bradley; Mike Jones
Cc: oauth
Subject: Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience

+1

Also, I have always thought that it would be good if one could ask for a particular resource type, and the server could respond with the actual location of it with the associated access token. This is because it is often undesirable to tell the client the location of the resource before the authorization from the privacy point of view.

  1.  The client request an access to the resource type in the scope of the authorization request.
  2.  The client request an access token to the resource type to the token endpoint with audience/resource/scope parameter.
  3.  The token endpoint responds with token response with oauth-meta header indicating the URL of the resource as in  draft-sakimura-oauth-meta.
Best,

Nat

2016年1月21日(木) 7:27 John Bradley <[email-masked]<mailto:[email-masked]>>:
+1

On Jan 20, 2016, at 7:25 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

                                                                -- Mike

Ciao
Hannes

---

From: John Bradley <[email-masked]>
Date: Wed, 20 Jan 2016 19:55:32 -0300

We have been talking about providing the resource or audience as the input.

The resource type would be more abstract than audience.  

That is something we would need to discuss in a spec.

The problem foe POP is that the same scope may cover multiple resource endpoints.  Especially when using a symmetric key you need to specify what Resource server you are sending the token to so that it can be encrypted with the correct key.

John B.
> On Jan 20, 2016, at 7:47 PM, Nat Sakimura <[email-masked]> wrote:
> 
> +1
> 
> The client request an access to the resource type in the scope of the authorization request. 
> The client request an access token to the resource type to the token endpoint with audience/resource/scope parameter. 
> The token endpoint responds with token response with oauth-meta header indicating the URL of the resource as in  draft-sakimura-oauth-meta. 
> Best, 
> 
> Nat
> 
> 
> 2016年1月21日(木) 7:27 John Bradley <[email-masked] <mailto:[email-masked]>>:
> +1
> 
>> On Jan 20, 2016, at 7:25 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Mike Jones <[email-masked]>
Date: Wed, 20 Jan 2016 22:56:48 +0000

As I see it, John just said the same thing I did in parallel, using different words.

From: John Bradley [mailto:[email-masked]]
Sent: Wednesday, January 20, 2016 2:56 PM
To: Nat Sakimura
Cc: Mike Jones; oauth
Subject: Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience

John B.
On Jan 20, 2016, at 7:47 PM, Nat Sakimura <[email-masked]<mailto:[email-masked]>> wrote:

+1

Nat

                                                                -- Mike

Ciao
Hannes

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 20 Jan 2016 23:06:02 +0000

Correct. I am not saying specifying resource URI as audience is a bad
thing. In fact, I need it as described below. I am just asking for adding
another option.

For John's case, if the client started from an abstract resource type, then
the token endpoint first responds with the tokens and set of possible
resource endpoints, preferably with more specific rels.
Then, the client can make a second token request using the refresh token,
this time with the concrete resource endpoint URI, to get the access token
to that location.

Nat

2016年1月21日(木) 7:56 Mike Jones <[email-masked]>:

> *From:* John Bradley [mailto:[email-masked]]
> *Sent:* Wednesday, January 20, 2016 2:56 PM
> *To:* Nat Sakimura
> *Cc:* Mike Jones; oauth
>
>
> The problem foe POP is that the same scope may cover multiple resource
> endpoints.  Especially when using a symmetric key you need to specify what
> Resource server you are sending the token to so that it can be encrypted
> with the correct key.
>
>
>
> John B.
>
>    2. The client request an access token to the resource type to the
>    token endpoint with audience/resource/scope parameter.
>    header indicating the URL of the resource as in  draft-sakimura-oauth-meta.
>
> Best,
>
>
>
> Nat
>
>
>
>
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 21 Jan 2016 09:57:19 +0000

Hi Hannes,
thanks for supporting it, I agree the audience concept is not tied to 
the PoP work

Cheers, Sergey

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 21 Jan 2016 10:05:02 +0000

Hi Brian

In our own code both authorization code and implicit flow requests can 
accommodate an audience property too.
You are right in the latter case there won't be a separate request to a 
token endpoint hence we are treating what follows after the user has 
authorized the implicit client as if it were a token endpoint request.

Not sure about using the audience property in the code flow but I guess 
it can be useful too - for example, the user may be shown this property, 
and then when the client requests a token and happens to supply an 
audience property alongside the code then this audience will have to 
match the one stored in the code grant data...

Cheers, Sergey

On 20/01/16 22:18, Brian Campbell wrote:
> There does seem to be a need to provide the client a means of telling
> the AS the place(s) and/or entity(s) where it intends to use the token
> it's asking for. And that it's common enough to warrant it's own small
> spec. This has come up several times before and I think has some
> consensus behind doing it. What needs to happen to move forward?
>
> All the above apply only to the token request. However, there are ways
> of requesting/obtaining access tokens that don't involve the token
> endpoint <https://tools.ietf.org/html/rfc6749#section-4.2> so I think it
> follows that  the same facility should be available for the
> authorization request too.
>
>
>
>
> On Wed, Jan 20, 2016 at 7:27 AM, Hannes Tschofenig
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Sergey,
>