Subject: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 28 Jul 2014 19:33:19 +0200

Hi all,

during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Token Introspection"
(draft-richer-oauth-introspection-06.txt) specification as an OAuth WG
work item.

We would now like to verify the outcome of this call for adoption on the
OAuth WG mailing list. Here is the link to the document:
http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/

If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion
as to the suitability of adopting this document as a WG work item,
please send mail to the OAuth WG list indicating your opinion (Yes/No).

The confirmation call for adoption will last until August 10, 2014.  If
you have issues/edits/comments on the document, please send these
comments along to the list in your response to this Call for Adoption.

Ciao
Hannes & Derek

---

From: Eve Maler <[email-masked]>
Date: Mon, 28 Jul 2014 10:56:07 -0700

Yes. This spec is of particular interest to UMA, for which it's valuable to have a standardized and interoperable way to perform run-time token introspection at the AS. To see how UMA uses profiles the existing token introspection spec, see this section and its subsections:

http://tools.ietf.org/html/draft-hardjono-oauth-umacore-10#section-3.3

	Eve

On 28 Jul 2014, at 10:33 AM, Hannes Tschofenig <[email-masked]> wrote:

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

Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl

---

From: Bill Mills <[email-masked]>
Date: Mon, 28 Jul 2014 11:46:17 -0700

+1 adoption

On Monday, July 28, 2014 11:41 AM, Hannes Tschofenig <[email-masked]> wrote:

Hi all,

Ciao
Hannes & Derek

---

From: Thomas Broyer <[email-masked]>
Date: Tue, 29 Jul 2014 02:00:46 +0200

Yes. This spec is of special interest to the platform we're building for
http://www.oasis-eu.org/

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 28 Jul 2014 17:11:11 -0700

Could we have some discussion on the interop cases?

Is it driven by scenarios where AS and resource are separate domains? Or may this be only of interest to specific protocols like UMA?

From a technique principle, the draft is important and sound. I am just not there yet on the reasons for an interoperable standard. 

Phil

> On Jul 28, 2014, at 17:00, Thomas Broyer <[email-masked]> wrote:
> 
> Yes. This spec is of special interest to the platform we're building for http://www.oasis-eu.org/
> 
> 
>> On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig <[email-masked]> wrote:
>> Hi all,
>> 
> /tɔ.ma.bʁwa.je/

---

From: Justin Richer <[email-masked]>
Date: Mon, 28 Jul 2014 20:39:54 -0400

It's analogous to JWT in many ways: when you've got the AS and the RS 
separated somehow (different box, different domain, even different 
software vendor) and you need to communicate a set of information about 
the approval delegation from the AS (who has the context to know about 
it) through to the RS (who needs to know about it to make the 
authorization call). JWT gives us an interoperable way to do this by 
passing values inside the token itself, introspection gives a way to 
pass the values by reference via the token as an artifact. The two are 
complementary, and there are even cases where you'd want to deploy them 
together.

  -- Justin

On 7/28/2014 8:11 PM, Phil Hunt wrote:
> Is it driven by scenarios where AS and resource are separate domains? 
> Or may this be only of interest to specific protocols like UMA?
>
> From a technique principle, the draft is important and sound. I am 
> just not there yet on the reasons for an interoperable standard.
>
> Phil
>
> On Jul 28, 2014, at 17:00, Thomas Broyer <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     Hi all,
>>
>>     [email-masked] <mailto:[email-masked]>
>> /t?.ma.b?wa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>
>> [email-masked] <mailto:[email-masked]>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 28 Jul 2014 17:59:05 -0700

That doesn’t explain the need for inter-operability. What you’ve described is what will be common practice.

It’s a great open source technique, but that’s not a standard.

JWT is much different. JWT is a foundational specification that describes the construction and parsing of JSON based tokens. There is inter-op with token formats that build on top and there is inter-op between every communicating party.

In OAuth, a site may never implement token introspection nor may it do it the way you describe.  Why would that be a problem?  Why should the group spend time on something where there may be no inter-op need.

Now that said, if you are in the UMA community.  Inter-op is quite foundational.  It is very very important. But then maybe the spec should be defined within UMA?

Phil

@independentid
www.independentid.com
[email-masked]

On Jul 28, 2014, at 5:39 PM, Justin Richer <[email-masked]> wrote:

> It's analogous to JWT in many ways: when you've got the AS and the RS separated somehow (different box, different domain, even different software vendor) and you need to communicate a set of information about the approval delegation from the AS (who has the context to know about it) through to the RS (who needs to know about it to make the authorization call). JWT gives us an interoperable way to do this by passing values inside the token itself, introspection gives a way to pass the values by reference via the token as an artifact. The two are complementary, and there are even cases where you'd want to deploy them together.
> 
>  -- Justin
>

---

From: Thomas Broyer <[email-masked]>
Date: Tue, 29 Jul 2014 03:16:26 +0200

Interesting question.

In our specific case, we don't really *need* interop as we have a single
AS, so the protocol could be specific to our needs. Building on a standard
however means that it might be easier to find software libraries
implementing it that could be used to build apps for our platform.
Similarly: we use OpenID Connect but we could have defined our own protocol
that issues OAuth access tokens. The benefit of standards are peer reviews
(particularly of privacy and security concerns) and software libraries.

>From my PoV, this goes along with registration: you register an app to an
AS, and if the app exposes resources protected using OAuth then it can use
introspection to allow/deny access. Interop of introspection is as
necessary as interop of registration; it means an app can easily be
"portable": deployable in different environments provided they implement
introspection (and/or registration, and/or OpenID Connect, etc.)
Maybe it falls under the UMA scope more than the OAuth WG though
(registration is not enough, you also need to register "resource sets" with
their scopes).

On Tue, Jul 29, 2014 at 2:11 AM, Phil Hunt <[email-masked]> wrote:

> Is it driven by scenarios where AS and resource are separate domains? Or
> may this be only of interest to specific protocols like UMA?
>
> From a technique principle, the draft is important and sound. I am just
> not there yet on the reasons for an interoperable standard.
>
> Phil
>

---

From: Justin Richer <[email-masked]>
Date: Mon, 28 Jul 2014 21:23:49 -0400

I think this perspective has a lot to do with your idea of OAuth's 
deployment model. You're right in that many people bundle the RS and the 
AS very tightly, but that's not always case, nor is it desirable. We're 
increasingly seeing cases where a group (often an enterprise) has their 
own AS on premises and wants to stand up an RS from a vendor. Without a 
means to connect the RS to the AS in a standard way, you're stuck with 
using whatever AS the RS vendor wants to sell you along side their RS. 
But with the right mechanisms (like JWT and token introspection), you're 
able to connect the RS from one vendor to the AS from another vendor, 
and it works together. I'm not sure what's unclear, but this is the very 
definition of interoperability.

This is to say nothing of simply being able to locate the RS remotely 
from the AS within a particular security domain and still use 
artifact-style tokens (ie, tokens that don't encode everything within 
them).

I have already had to deal directly with several cases of RS'es and 
AS'es from different vendors doing effectively the token introspection 
thing in different ways, in protecting vanilla OAuth within a single 
security domain. They were doing it slightly differently for no 
compelling reason other than having to invent the "I have a token and 
need to look it up" mechanism independently. When both sides were able 
to speak the same token introspection protocol (based on the individual 
draft I'd submitted), then we could actually make things work. And none 
of this was running UMA, which also makes use of this.

I really don't see JWT as any different. To borrow your statement: In 
OAuth, a site may never implement JWT nor may it do it in the way that 
JWT describes. Why would that be a problem? (Hint: it isn't, they're 
free to do whatever token they want. Same with introspection, it's a 
tool that you can use if it makes sense for you to use it. So far a 
whole bunch of people have said it makes sense.)

  -- Justin

On 7/28/2014 8:59 PM, Phil Hunt wrote:
> That doesn’t explain the need for inter-operability. What you’ve 
> described is what will be common practice.
>
> JWT is much different. JWT is a foundational specification that 
> describes the construction and parsing of JSON based tokens. There is 
> inter-op with token formats that build on top and there is inter-op 
> between every communicating party.
>
> In OAuth, a site may never implement token introspection nor may it do 
> it the way you describe.  Why would that be a problem?  Why should the 
> group spend time on something where there may be no inter-op need.
>
> Now that said, if you are in the UMA community.  Inter-op is quite 
> foundational.  It is very very important. But then maybe the spec 
> should be defined within UMA?
>
> Phil
>
> @independentid
> www.independentid.com <http://www.independentid.com>
> [email-masked] <mailto:[email-masked]>
>
>
>
> On Jul 28, 2014, at 5:39 PM, Justin Richer <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> software vendor) and you need to communicate a set of information 
>> about the approval delegation from the AS (who has the context to 
>> know about it) through to the RS (who needs to know about it to make 
>> the authorization call). JWT gives us an interoperable way to do this 
>> by passing values inside the token itself, introspection gives a way 
>> to pass the values by reference via the token as an artifact. The two 
>> are complementary, and there are even cases where you'd want to 
>> deploy them together.
>>
>>  -- Justin
>>
>>> Is it driven by scenarios where AS and resource are separate 
>>> domains? Or may this be only of interest to specific protocols like UMA?
>>>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 29 Jul 2014 06:57:01 +0000

+1 support for adoption. This draft is useful for PCP third party authorization http://tools.ietf.org/html/draft-wing-pcp-third-party-authz-03, where PCP server in the Enterprise network (Resource server) and WebRTC server (Authorization server) are in different administrative domains. PCP third party authorization is using handle token and need a standard communication mechanism b/w RS and AS to validate token. RS and AS are provided by different vendors and need interoperability.

-Tiru

> -----Original Message-----
> From: OAuth [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
> Sent: Monday, July 28, 2014 11:03 PM
> To: [email-masked]
> Subject: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token
> Introspection" as an OAuth Working Group Item
> 
> Hi all,
> 
> during the IETF #90 OAuth WG meeting, there was strong consensus in adopting
> the "OAuth Token Introspection"
> (draft-richer-oauth-introspection-06.txt) specification as an OAuth WG work
> item.
> 
> We would now like to verify the outcome of this call for adoption on the OAuth
> WG mailing list. Here is the link to the document:
> If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion as to
> the suitability of adopting this document as a WG work item, please send mail to
> the OAuth WG list indicating your opinion (Yes/No).
> 
> The confirmation call for adoption will last until August 10, 2014.  If you have
> issues/edits/comments on the document, please send these comments along to
> the list in your response to this Call for Adoption.
> 
> Ciao
> Hannes & Derek

---

From: Mark Dobrinic <[email-masked]>
Date: Tue, 29 Jul 2014 11:46:38 +0200

Just some way I could look at this discussion:

One way to separate an AS and an RS is specified by UMA, so for UMA it
is required to have a standardized Token Introspection feature.

If there are no other uses for separating AS/RS, then UMA would be the
place for standardizing Token Introspection.

On the other hand, if there might be other uses for a standardized Token
Introspection, then it would make the most sense that it would be made a
feature of the set of OAuth specifications.

Personally, I've been surprised to find that the main OAuth spec does
not specify a standard way to return a token's info.

Cheers!

Mark

---

From: Paul Madsen <[email-masked]>
Date: Tue, 29 Jul 2014 05:47:55 -0400

Standardized Introspection will be valuable in NAPPS, where the AS and RS may be in different policy domains.

Even for single policy domains, there are enterprise scenarios where the RS is from a different vendor than the AS, such as when an API gateway validates tokens issued by an 'IdP' . We've necessarily defined our own introspection endpoint and our gateway partners have implemented it, (at the instruction of the customer in question). But of course it's proprietary to us.

Paul

> On Jul 28, 2014, at 8:59 PM, Phil Hunt <[email-masked]> wrote:
>

---

From: Mike Jones <[email-masked]>
Date: Tue, 29 Jul 2014 17:15:20 +0000

As I see it, there are two different kinds of standardization for introspection that could occur.  One is defining a standard endpoint for doing introspection on an access token and possibly refresh token.  The other is defining standard contents to be returned from the introspection.

I’m skeptical of the standard contents, given that access tokens and refresh tokens are intentionally opaque.  Implementations could range from being an integer index into a database table, to being a UUID to being an encrypted JWT with context-specific claims.  I don’t see anything in common in those implementations for introspection to return.

While I can see marginal utility to having a common endpoint and request syntax, I would be against trying to standardize the contents of what an introspection request might return.  It’s as deployment-specific as the access token representation itself.

                                                            -- Mike

From: OAuth [mailto:[email-masked]] On Behalf Of Paul Madsen
Sent: Tuesday, July 29, 2014 2:48 AM
To: Phil Hunt
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item

Paul

On Jul 28, 2014, at 8:59 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
That doesn’t explain the need for inter-operability. What you’ve described is what will be common practice.

Phil

@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

On Jul 28, 2014, at 5:39 PM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

 -- Justin

Phil

On Jul 28, 2014, at 17:00, Thomas Broyer <[email-masked]<mailto:[email-masked]>> wrote:
Yes. This spec is of special interest to the platform we're building for http://www.oasis-eu.org/

On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Ciao
Hannes & Derek

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

--
Thomas Broyer
/tɔ.ma.bʁwa.je/<http://xn--nna.ma.xn--bwa-xxb.je/>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

OAuth mailing list

[email-masked]<mailto:[email-masked]>

_______________________________________________
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: Justin Richer <[email-masked]>
Date: Tue, 29 Jul 2014 13:36:38 -0400

I disagree with this position and think it's vital to standardize a 
return structure and a common set of return values -- and that this work 
would be rather pointless without it. Mike, I think you might be 
thinking in terms of introspection simply unpacking what's already 
contained inside the token, and the AS doing the effort of unpacking 
that for the RS. This is, after all, what used to be the case for the 
now-defunct OpenID Connect "CheckID Endpoint". But what's really 
happening here is this general pattern:

  - The client passes the token to the RS. The client doesn't know or 
care what's in the token or what it's used for, it just knows that it 
can use the token at the RS.
  - The RS gets the token and passes it along to the introspection 
endpoint on the AS. The means by which the RS figures out where its AS 
is is out of scope for this bit of work.
  - The AS is looking at the token as passed in, (whether it's 
structured like a JWT, a random UUID, an integer into a DB, whatever 
deployment-specific bit you want) and figures out if the token is any 
good and what it's for. The AS can do this in whatever 
deployment-specific way it wants to: look up the token in a DB, unpack 
the JWT and check the signature, decrypt the token's payload, whatever.
  - The AS returns (in a standardized JSON object) a set of claims about 
the token. While it's possible that these claims can be included in the 
token directly (as a JWT, for instance) and the RS could have read them 
if it knew how to parse said token, it's important that they don't have 
to be communicated that way and the token itself does not have to be 
structured at all. The AS can literally issue a token of "foo.bar.123" 
and the RS can do an introspection call to turn "foo.bar.123" into 
{valid: true, sub: user-person, aud: resource-server, ... }
  - The RS looks at the returned JSON value and uses that to make its 
authorization decision.

It's imperative to note that the token in OAuth is opaque to the 
*client* -- it is not opaque to other parties, namely the AS. And in 
most deployments, it's not opaque to the RS either, since the RS has to 
be able to turn the OAuth token into something that can help it make 
authorization decisions. Having an introspection endpoint with a 
standardized return value would actually allow the token content itself 
to be opaque to the RS as well as the Client.

All that said, I think there is enough variability and flexibility in 
OAuth deployments that the introspection data response should (and so 
far, has) follow the JWT model: define a core set of claims with clear 
semantics, make them all optional apart from the common "active" field, 
and allow for copious extension. It's a very simple, very useful pattern 
that's been implemented by many different developers.

  -- Justin

On 07/29/2014 01:15 PM, Mike Jones wrote:
>
> As I see it, there are two different kinds of standardization for 
> introspection that could occur.  One is defining a standard endpoint 
> for doing introspection on an access token and possibly refresh 
> token.  The other is defining standard contents to be returned from 
> the introspection.
>
> I'm skeptical of the standard contents, given that access tokens and 
> refresh tokens are intentionally opaque. Implementations could range 
> from being an integer index into a database table, to being a UUID to 
> being an encrypted JWT with context-specific claims.  I don't see 
> anything in common in those implementations for introspection to return.
>
> While I can see marginal utility to having a common endpoint and 
> request syntax, I would be against trying to standardize the contents 
> of what an introspection request might return. It's as 
> deployment-specific as the access token representation itself.
>
> -- Mike
>
> *From:*OAuth [mailto:[email-masked]] *On Behalf Of *Paul Madsen
> *Sent:* Tuesday, July 29, 2014 2:48 AM
> *To:* Phil Hunt
> *Cc:* [email-masked]
> *Subject:* Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth 
> Token Introspection" as an OAuth Working Group Item
>
> Even for single policy domains, there are enterprise scenarios where 
> the RS is from a different vendor than the AS, such as when an API 
> gateway validates tokens issued by an 'IdP' . We've necessarily 
> defined our own introspection endpoint and our gateway partners have 
> implemented it, (at the instruction of the customer in question). But 
> of course it's proprietary to us.
>
> Paul
>
>
>     That doesn't explain the need for inter-operability. What you've
>     It's a great open source technique, but that's not a standard.
>
>     describes the construction and parsing of JSON based tokens. There
>     is inter-op with token formats that build on top and there is
>     inter-op between every communicating party.
>
>     In OAuth, a site may never implement token introspection nor may
>     it do it the way you describe.  Why would that be a problem?  Why
>     should the group spend time on something where there may be no
>     inter-op need.
>
>     It's analogous to JWT in many ways: when you've got the AS and the
>     RS separated somehow (different box, different domain, even
>     different software vendor) and you need to communicate a set of
>     information about the approval delegation from the AS (who has the
>     context to know about it) through to the RS (who needs to know
>     about it to make the authorization call). JWT gives us an
>     interoperable way to do this by passing values inside the token
>     itself, introspection gives a way to pass the values by reference
>     via the token as an artifact. The two are complementary, and there
>     are even cases where you'd want to deploy them together.
>
>      -- Justin
>
>         From a technique principle, the draft is important and sound.
>         I am just not there yet on the reasons for an interoperable
>         standard.
>
>         Phil
>
>
>             Yes. This spec is of special interest to the platform
>             we're building for http://www.oasis-eu.org/
>
>             <[email-masked]
>             <mailto:[email-masked]>> wrote:
>
>             Hi all,
>

---

From: Bill Mills <[email-masked]>
Date: Tue, 29 Jul 2014 11:11:28 -0700

This is exactly the same problem space as webfinger, you want to know something about a user and there's a useful set of information you might reasonably query, but in the end the server may have it's own schema of data it returns.  There won't be a single schema that fits all use cases, Any given RS/AS ecosystem may decide they have custom stuff and omit other stuff.  I think the more rigid the MTI schema gets the harder the battle in this case.

On Tuesday, July 29, 2014 2:56 AM, Paul Madsen <[email-masked]> wrote:

Paul

>[email-masked]
>
>
>
>
-- 
>>>>/tɔ.ma.bʁwa.je/ 
OAuth mailing list [email-masked] https://www.ietf.org/mailman/listinfo/oauth

---

From: Justin Richer <[email-masked]>
Date: Tue, 29 Jul 2014 14:13:04 -0400

Agreed on this point -- which is why the only MTI bit in the individual 
draft is "active", which is whether or not the token was any good to 
begin with. There are a set of claims with defined semantics but all are 
optional, and the list is extensible. I think in practice we'll see 
people settle on a set of common ones.

  -- Justin

On 07/29/2014 02:11 PM, Bill Mills wrote:
> This is exactly the same problem space as webfinger, you want to know 
> something about a user and there's a useful set of information you 
> might reasonably query, but in the end the server may have it's own 
> schema of data it returns.  There won't be a single schema that fits 
> all use cases, Any given RS/AS ecosystem may decide they have custom 
> stuff and omit other stuff.  I think the more rigid the MTI schema 
> gets the harder the battle in this case.
>
>
>> In OAuth, a site may never implement token introspection nor may it 
>> do it the way you describe.  Why would that be a problem?  Why should 
>> the group spend time on something where there may be no inter-op need.
>>
>> www.independentid.com <http://www.independentid.com/>
>>> context to know about it) through to the RS (who needs to know about 
>>> it to make the authorization call). JWT gives us an interoperable 
>>> way to do this by passing values inside the token itself, 
>>> introspection gives a way to pass the values by reference via the 
>>> token as an artifact. The two are complementary, and there are even 
>>> cases where you'd want to deploy them together.
>>>
>>>  -- Justin
>>>

---

From: Eve Maler <[email-masked]>
Date: Tue, 29 Jul 2014 12:08:47 -0700

Agreed on this point too, and also wanted to point out that the UMA usage of token introspection calls out to Justin's latest draft and formally profiles it, which we found easy to do. UMA has a mandatory-to-implement token format but also an extensible framework for defining whatever format suits. The method of run-time introspection at the AS, on the other hand, is locked down to increase interop.

	Eve

On 29 Jul 2014, at 11:13 AM, Justin Richer <[email-masked]> wrote:

> Agreed on this point -- which is why the only MTI bit in the individual draft is "active", which is whether or not the token was any good to begin with. There are a set of claims with defined semantics but all are optional, and the list is extensible. I think in practice we'll see people settle on a set of common ones.
> 
>  -- Justin
>

---

From: Phil Hunt <[email-masked]>
Date: Tue, 29 Jul 2014 13:41:16 -0700

Making everything optional achieves no benefits, you just end up with a complex set of options and no inter op. 

We had the same issue with dyn reg. 

I prefer to first get agreement on use case. 

What are the questions a caller can ask and what form of responses are available. 

Should this be limited to authz info or is this a back door for user data and wbfinger data?

I would prefer to have agreement on use cases before picking a solution right now. 

Phil

> On Jul 29, 2014, at 11:13, Justin Richer <[email-masked]> wrote:
>

---

From: Thomas Broyer <[email-masked]>
Date: Tue, 29 Jul 2014 23:31:21 +0200

> I would prefer to have agreement on use cases before picking a solution

The use-case (in our case) is driving authorization at an RS from a
different vendor than the AS (we have a single AS, and everyone is free to
register a RS in the AS catalog), as explained by Justin 3 hours ago.

If the response is {"active":false}, the RS is supposed to reply with a 401
and invalid_token. This could happen if the token is invalid/unknown to the
AS, expired, or does not grant any scope registered by the calling
RS (identified by HTTP Basic auth –Client Authentication– at the endpoint).
Our "active":true responses include the "scope" claim filtered to only
include the scopes registered by the calling RS, so it can possibly return
a 403 with insufficient_scope.
They also include the "sub" claim and a custom "sub_groups" claim so the RS
can drive authorization depending on the user. Our "sub_groups" claim
includes identifiers for groups the user is a member of (so that you could
control access by groups rather than only a list of users).
Finally, we also send the "client_id" claim so the RS could identify who
uses its data, and possibly charge them accordingly (or refuse them access
if they need prior, out-of-band, approval, or they've been blacklisted,
etc.), and the "iat" and "exp" claims so they could possibly refuse access
if the token is not recent enough or will expire too soon.

In due course, we'll probably add "amr" and/or "acr" claims (or similar)
because some processes (in France for example) require the use of client
certificates, etc.

---

From: George Fletcher <[email-masked]>
Date: Tue, 29 Jul 2014 18:24:44 -0400

We also have a use case where the AS is provided by a partner and the RS 
is provided by AOL. Being able to have a standardized way of validating 
and getting data about the token from the AS would make our 
implementation much simpler as we can use the same mechanism for all 
Authorization Servers and not have to implement one off solutions for 
each AS.

Thanks,
George

---

From: Phil Hunt <[email-masked]>
Date: Tue, 29 Jul 2014 16:44:34 -0700

Thanks everyone for the comments.

It sounds like we have multiple dimensions to introspection features and requirements: 

* there are UMA cases, 
* corporate third-party AS-RS relationships (e.g. the RS chooses a third-party AS), 
* multi-vendor cases, 
* tooling/library cases,

There’s also federation cases. Federated authorization seems like a different problem than federated authentication from a trust perspective.

Another dimension to this is methodology:
1.  Lookup by token / token id / reference
2.  Query by token / token id / reference
3.  Passing standardized information in a standardized token format or token URI.

There may be some complex privacy issues involved as well. For example, in many cases, the desire is to allow authz information *only* the actual content owner / delegator may be intentionally pseudonymous.

I would support first developing a use case document to figure out if there is an appropriate pattern that can satisfy (and simplify) a majority of cases.

Phil

@independentid
www.independentid.com
[email-masked]

On Jul 29, 2014, at 3:24 PM, George Fletcher <[email-masked]> wrote:

> We also have a use case where the AS is provided by a partner and the RS is provided by AOL. Being able to have a standardized way of validating and getting data about the token from the AS would make our implementation much simpler as we can use the same mechanism for all Authorization Servers and not have to implement one off solutions for each AS.
> 
> Thanks,
> George
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 30 Jul 2014 00:16:28 +0000

Did you consider standardizing the access token format within that deployment so all the parties that needed to could understand it, rather requiring an extra round trip to an introspection endpoint so as to be able to understand things about it?

I realize that might or might not be practical in some cases, but I haven’t heard that alternative discussed, so I thought I’d bring it up.

I also second Phil’s comment that it would be good to understand the use cases that this is intended to solve before embarking on a particular solution path.

                                                            -- Mike

From: OAuth [mailto:[email-masked]] On Behalf Of George Fletcher
Sent: Tuesday, July 29, 2014 3:25 PM
To: Phil Hunt; Thomas Broyer
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item

Thanks,
George

Phil

Ciao
Hannes & Derek

OAuth mailing list

---

From: Thomas Broyer <[email-masked]>
Date: Wed, 30 Jul 2014 02:42:42 +0200

Decoding a token with a specific format wouldn't tell you whether the token
is still live: it could have been revoked before its expiration.
Le 30 juil. 2014 02:16, "Mike Jones" <[email-masked]> a écrit :

>  Did you consider standardizing the access token format within that
> deployment so all the parties that needed to could understand it, rather
> requiring an extra round trip to an introspection endpoint so as to be able
> to understand things about it?
>
>
>
> I realize that might or might not be practical in some cases, but I
> haven’t heard that alternative discussed, so I thought I’d bring it up.
>
>
>
> I also second Phil’s comment that it would be good to understand the use
> cases that this is intended to solve before embarking on a particular
> solution path.
>
>
>
>                                                             -- Mike
>
>
>
> *From:* OAuth [mailto:[email-masked]] *On Behalf Of *George
> Fletcher
> *Sent:* Tuesday, July 29, 2014 3:25 PM
> *To:* Phil Hunt; Thomas Broyer
> *Cc:* [email-masked]
> *Subject:* Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token
> is provided by AOL. Being able to have a standardized way of validating and
> getting data about the token from the AS would make our implementation much
> simpler as we can use the same mechanism for all Authorization Servers and
> not have to implement one off solutions for each AS.
>
> Thanks,
> George
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 30 Jul 2014 00:49:23 +0000

Yes, but that’s the simplest thing to determine – try the token and see whether it works or not.

From: Thomas Broyer [mailto:[email-masked]]
Sent: Tuesday, July 29, 2014 5:43 PM
To: Mike Jones
Cc: <[email-masked]>; George Fletcher; Phil Hunt
Subject: RE: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item

Decoding a token with a specific format wouldn't tell you whether the token is still live: it could have been revoked before its expiration.
Le 30 juil. 2014 02:16, "Mike Jones" <[email-masked]<mailto:[email-masked]>> a écrit :
Did you consider standardizing the access token format within that deployment so all the parties that needed to could understand it, rather requiring an extra round trip to an introspection endpoint so as to be able to understand things about it?

                                                            -- Mike

From: OAuth [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of George Fletcher
Sent: Tuesday, July 29, 2014 3:25 PM
To: Phil Hunt; Thomas Broyer
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item

Thanks,
George

Phil

Ciao
Hannes & Derek

OAuth mailing list

---

From: Justin Richer <[email-masked]>
Date: Tue, 29 Jul 2014 20:50:42 -0400

Not true if I revoke the token after it's been issued but before it expires.

On 7/29/2014 8:49 PM, Mike Jones wrote:
>
> Yes, but that's the simplest thing to determine -- try the token and 
> see whether it works or not.
>
> *From:*Thomas Broyer [mailto:[email-masked]]
> *Sent:* Tuesday, July 29, 2014 5:43 PM
> *To:* Mike Jones
> *Cc:* <[email-masked]>; George Fletcher; Phil Hunt
> *Subject:* RE: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth 
> Decoding a token with a specific format wouldn't tell you whether the 
> token is still live: it could have been revoked before its expiration.
>
> Le 30 juil. 2014 02:16, "Mike Jones" <[email-masked] 
> <mailto:[email-masked]>> a écrit :
>
> deployment so all the parties that needed to could understand it, 
> rather requiring an extra round trip to an introspection endpoint so 
> as to be able to understand things about it?
>
> haven't heard that alternative discussed, so I thought I'd bring it up.
>
> I also second Phil's comment that it would be good to understand the 
> use cases that this is intended to solve before embarking on a 
> particular solution path.
>
> -- Mike
>
> *From:*OAuth [mailto:[email-masked] 
> <mailto:[email-masked]>] *On Behalf Of *George Fletcher
> *Cc:* [email-masked] <mailto:[email-masked]>
> We also have a use case where the AS is provided by a partner and the 
> RS is provided by AOL. Being able to have a standardized way of 
> validating and getting data about the token from the AS would make our

---

From: Justin Richer <[email-masked]>
Date: Tue, 29 Jul 2014 20:52:35 -0400

Reading through this thread, it appears very clear to me that the use 
cases are very well established by a number of existing implementers who 
want to work together to build a common standard. I see no reason to 
delay the work artificially by creating a use case document when such a 
vast array of understanding and interest already exists. Any use cases 
and explanations of applications are welcome to be added to the working 
group draft as it progresses.

  -- Justin

On 7/29/2014 8:16 PM, Mike Jones wrote:
> *From:*OAuth [mailto:[email-masked]] *On Behalf Of *George 
> Fletcher

---

From: Phil Hunt <[email-masked]>
Date: Tue, 29 Jul 2014 17:54:51 -0700

-100

Phil

> On Jul 29, 2014, at 17:52, Justin Richer <[email-masked]> wrote:
> 
> Reading through this thread, it appears very clear to me that the use cases are very well established by a number of existing implementers who want to work together to build a common standard. I see no reason to delay the work artificially by creating a use case document when such a vast array of understanding and interest already exists. Any use cases and explanations of applications are welcome to be added to the working group draft as it progresses.
> 
>  -- Justin
> 
>

---

From: Thomas Broyer <[email-masked]>
Date: Wed, 30 Jul 2014 02:55:20 +0200

Try it where? When you're the RS trying to determine whether you should
accept the token or reject it?
Le 30 juil. 2014 02:49, "Mike Jones" <[email-masked]> a écrit :

> *From:* Thomas Broyer [mailto:[email-masked]]
> *Subject:* RE: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token

---

From: Phil Hunt <[email-masked]>
Date: Tue, 29 Jul 2014 18:02:44 -0700

I think one alternative to an introspection service is a revocation status service. 

But it is often not needed if token lifetimes are small (minutes / session life) compared to the refresh token which might last much longer. 

Again having info on the case helps explain the requirements of your case and we can tell what the best pattern is. 

Phil

> On Jul 29, 2014, at 17:55, Thomas Broyer <[email-masked]> wrote:
> 
> Try it where? When you're the RS trying to determine whether you should accept the token or reject it?
>

---

From: Justin Richer <[email-masked]>
Date: Tue, 29 Jul 2014 21:07:39 -0400

So you want a service where the RS can call an HTTP endpoint to see if 
the token is alive or not? That sounds like an awesome idea! Very useful 
for a variety of use cases that people have already mentioned on that 
list. Maybe that service should respond in JSON with, say, { "active": 
true } if it's still valid. That's a great start, and that should 
obviously be MTI.

But while we're there, we probably want to know what else the token is 
for, since this service will probably know that, so let's add in the 
"scope" and "client_id" and whatever other meta-information we have 
about the token. If this endpoint doesn't have that information? Well 
then, I guess it can't return it. So we need to make sure to be flexible 
about that while we define a common core set of semantics. Flexibility 
like that is very powerful and could be used in a variety of protocols 
and deployments across domains and vendors.

You know, this idea is sounding better and better. In fact, I'll do you 
one better. I think this is such a fantastic idea that I wrote it all 
down in RFC format:

http://tools.ietf.org/html/draft-richer-oauth-introspection-06

Glad to have you on board, Phil.

  -- Justin

On 7/29/2014 9:02 PM, Phil Hunt wrote:
> But it is often not needed if token lifetimes are small (minutes / 
> session life) compared to the refresh token which might last much longer.
>
> Again having info on the case helps explain the requirements of your 
> case and we can tell what the best pattern is.
>
> Phil
>
> On Jul 29, 2014, at 17:55, Thomas Broyer <[email-masked] 
>> Le 30 juil. 2014 02:49, "Mike Jones" <[email-masked] 
>>     Yes, but that's the simplest thing to determine -- try the token
>>     and see whether it works or not.
>>
>>     *From:*Thomas Broyer [mailto:[email-masked]
>>     <mailto:[email-masked]>]
>>     *Cc:* <[email-masked] <mailto:[email-masked]>>; George Fletcher;
>>     Phil Hunt
>>     *Subject:* RE: [OAUTH-WG] Confirmation: Call for Adoption of
>>     "OAuth Token Introspection" as an OAuth Working Group Item
>>
>>     Decoding a token with a specific format wouldn't tell you whether
>>     the token is still live: it could have been revoked before its
>>     expiration.
>>
>>     Did you consider standardizing the access token format within
>>     that deployment so all the parties that needed to could
>>     understand it, rather requiring an extra round trip to an
>>     introspection endpoint so as to be able to understand things
>>     about it?
>>
>>     I realize that might or might not be practical in some cases, but
>>     I haven't heard that alternative discussed, so I thought I'd
>>     bring it up.
>>
>>     I also second Phil's comment that it would be good to understand
>>     the use cases that this is intended to solve before embarking on
>>     a particular solution path.
>>
>>     -- Mike
>>
>>     *Subject:* Re: [OAUTH-WG] Confirmation: Call for Adoption of
>>     "OAuth Token Introspection" as an OAuth Working Group Item
>>
>>     We also have a use case where the AS is provided by a partner and
>>     the RS is provided by AOL. Being able to have a standardized way
>>     of validating and getting data about the token from the AS would
>>     make our implementation much simpler as we can use the same
>>     mechanism for all Authorization Servers and not have to implement
>>     one off solutions for each AS.
>>
>>     Thanks,
>>     George
>>

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 30 Jul 2014 01:17:42 +0000

I think we need management APIs now to manage the new endpoint, but seriously this introspection proposal has privacy issues, to avoid these I would encrypt the tokens and then this would be a useless endpoint, also this has issues with symmetric POP tokens, but maybe this was only designed to work on bearer tokens.

From: OAuth [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Tuesday, July 29, 2014 6:08 PM
To: Phil Hunt; Thomas Broyer
Cc: <[email-masked]>
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item

So you want a service where the RS can call an HTTP endpoint to see if the token is alive or not? That sounds like an awesome idea! Very useful for a variety of use cases that people have already mentioned on that list. Maybe that service should respond in JSON with, say, { "active": true } if it's still valid. That's a great start, and that should obviously be MTI.

But while we're there, we probably want to know what else the token is for, since this service will probably know that, so let's add in the "scope" and "client_id" and whatever other meta-information we have about the token. If this endpoint doesn't have that information? Well then, I guess it can't return it. So we need to make sure to be flexible about that while we define a common core set of semantics. Flexibility like that is very powerful and could be used in a variety of protocols and deployments across domains and vendors.

You know, this idea is sounding better and better. In fact, I'll do you one better. I think this is such a fantastic idea that I wrote it all down in RFC format:

 -- Justin

Phil

On Jul 29, 2014, at 17:55, Thomas Broyer <[email-masked]<mailto:[email-masked]>> wrote:

Try it where? When you're the RS trying to determine whether you should accept the token or reject it?
Le 30 juil. 2014 02:49, "Mike Jones" <[email-masked]<mailto:[email-masked]>> a écrit :
Yes, but that’s the simplest thing to determine – try the token and see whether it works or not.

From: Thomas Broyer [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, July 29, 2014 5:43 PM
To: Mike Jones
Cc: <[email-masked]<mailto:[email-masked]>>; George Fletcher; Phil Hunt
Subject: RE: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item

                                                            -- Mike

Thanks,
George

Phil

Ciao
Hannes & Derek

OAuth mailing list

OAuth mailing list

---

From: Phil Hunt <[email-masked]>
Date: Tue, 29 Jul 2014 18:17:49 -0700

Mike's proposal may be sufficient for Thomas' case given a small token lifetime. 

The federated cases may have other issues....

How does the RS know who issued the opaque token and what introspection point is authoritative? 

I am not saying your spec is not the right answer. I am just not prepared to limit functionality yet by adopting the draft until we have sufficient requirements understood. 

Let the rest of us catch up please. 

Phil

> On Jul 29, 2014, at 18:07, Justin Richer <[email-masked]> wrote:
>

---

From: Eve Maler <[email-masked]>
Date: Tue, 29 Jul 2014 18:45:21 -0700

I would say that if an RS and AS are relatively tightly coupled and have established their trust "off stage", then the RS will know where to go and how to interpret the results. If an RS and AS are entirely loosely coupled, then there are a number of options for trust establishment for which UMA provides one solution, leveraging an OAuth-protected token introspection endpoint and an endpoint discovery mechanism.

(BTW, I first wrote about this usage of token introspection on this list in November 2012, where I distinguished "shallow" and "deep" options for RS/AS communication.)

	Eve

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 30 Jul 2014 05:03:11 +0000

Token revocation will require unsolicited update from AS to RS that the token is no longer valid, it will be useful to add this communication mechanism in this draft.

-Tiru

From: OAuth [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Wednesday, July 30, 2014 6:21 AM
To: Mike Jones; Thomas Broyer
Cc: <[email-masked]>
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item

From: Thomas Broyer [mailto:[email-masked]]
Sent: Tuesday, July 29, 2014 5:43 PM
To: Mike Jones
Cc: <[email-masked]><mailto:[email-masked]>; George Fletcher; Phil Hunt
Subject: RE: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item

                                                            -- Mike

Thanks,
George

Phil

Ciao
Hannes & Derek

OAuth mailing list

OAuth mailing list

---

From: Thomas Broyer <[email-masked]>
Date: Wed, 30 Jul 2014 09:13:31 +0200

One issue with Mike's proposal is that all RSs receiving the token would
know all the scopes the token is valid for.

Imagine an app requesting access to scopes allowing it to see your bank
balance and retrieve your wish lists from another RS. It'll get it in the
form of a Bearer token with those two scopes, and will use it at the wish
list RS.
Now the wish list RS decodes the token and sees it grants access to your
bank balance. Because it's a bearer token, it now knows it can use it at
your bank and see your balance.
With opaque tokens and the introspection endpoint, the endpoint could just
tell the wish list RS the token is valid for it, without leaking the fact
it's also valid at your bank.

I know there are better alternatives but they all involve more complexity
for the clients and/or RSs. You won't believe me if I'd tell you how bad
are some developers at their work. I've seen some sending their client
secret as a parameter to the authorization endpoint and all sort of other
stupid things you'd never imagine a web dev to do. The OAuth dance is
already too complex for many, so adding crypto (PoP) or, e.g., asking them
to manage distinct tokens per RS is not realizable in practice. Not now at
least. And our platform goes live in one month from now and we want to have
an ecosystem of clients and resource servers.

When devs are lazy, wouldn't understand crypto, and treat security and
privacy as an afterthought, an introspection endpoint is the way to go.
Le 30 juil. 2014 03:17, "Phil Hunt" <[email-masked]> a écrit :

> I am not saying your spec is not the right answer. I am just not prepared
> to limit functionality yet by adopting the draft until we have sufficient
> requirements understood.
>
> So you want a service where the RS can call an HTTP endpoint to see if the
> token is alive or not? That sounds like an awesome idea! Very useful for a
> variety of use cases that people have already mentioned on that list. Maybe
> that service should respond in JSON with, say, { "active": true } if it's
> still valid. That's a great start, and that should obviously be MTI.
>
> "scope" and "client_id" and whatever other meta-information we have about
> the token. If this endpoint doesn't have that information? Well then, I
> guess it can't return it. So we need to make sure to be flexible about that
> while we define a common core set of semantics. Flexibility like that is
> very powerful and could be used in a variety of protocols and deployments
> across domains and vendors.
>
> one better. I think this is such a fantastic idea that I wrote it all down
> in RFC format:
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 30 Jul 2014 10:45:36 +0300

+1.

I've understood from what Justin said the idea is to introduce a 
standard way for RS to communicate to AS about the tokens issued by the 
AS. I think it is a good idea, I'd only not focus on the RS-to-3rd party 
AS communications because it complicates it a bit.

Clearly it would be of help to implementers of OAuth2 filters protecting 
RS, having a new lengthy process to collect the cases seems to be a very 
administrative idea to me

Thanks, Sergey

On 30/07/14 03:54, Phil Hunt wrote:
> -100
>
> Phil
>
> On Jul 29, 2014, at 17:52, Justin Richer <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>> cases are very well established by a number of existing implementers
>> who want to work together to build a common standard. I see no reason
>> to delay the work artificially by creating a use case document when
>> such a vast array of understanding and interest already exists. Any
>> use cases and explanations of applications are welcome to be added to
>> the working group draft as it progresses.
>>
>>  -- Justin
>>
>>
>>> I also second Phil’s comment that it would be good to understand the
>>> validating and getting data about the token from the AS would make
>>> our implementation much simpler as we can use the same mechanism for
>>> all Authorization Servers and not have to implement one off solutions
>>> for each AS.
>>>
>>> Thanks,
>>> George
>>>
>>>     From a technique principle, the draft is important and sound. I
>>>     am just not there yet on the reasons for an interoperable standard.
>>>
>>>     Phil
>>>
>>>

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 30 Jul 2014 10:49:26 +0300

On 30/07/14 04:45, Eve Maler wrote:
> I would say that if an RS and AS are relatively tightly coupled and have
> established their trust "off stage", then the RS will know where to go
> and how to interpret the results.
+1. It is an obvious answer, there has to be a trust established between 
RS and AS.
let me ask Phil: How does RS know today, when it asks AS to return the 
info about a given token that the AS endpoint is authoritative ?
Thanks, Sergey
> If an RS and AS are entirely loosely
> coupled, then there are a number of options for trust establishment for
> which UMA provides one solution, leveraging an OAuth-protected token
> introspection endpoint and an endpoint discovery mechanism.
>
> (BTW, I first wrote about this usage of token introspection on this list
> in November 2012
> <http://www.ietf.org/mail-archive/web/oauth/current/msg10230.html>,
> where I distinguished "shallow" and "deep" options for RS/AS communication.)
>
> Eve
>
> On 29 Jul 2014, at 6:17 PM, Phil Hunt <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>> I am not saying your spec is not the right answer. I am just not
>> prepared to limit functionality yet by adopting the draft until we
>> have sufficient requirements understood.
>>
>> On Jul 29, 2014, at 18:07, Justin Richer <[email-masked]
>>> So you want a service where the RS can call an HTTP endpoint to see
>>> if the token is alive or not? That sounds like an awesome idea! Very
>>> useful for a variety of use cases that people have already mentioned
>>> on that list. Maybe that service should respond in JSON with, say, {
>>> "active": true } if it's still valid. That's a great start, and that
>>> should obviously be MTI.
>>>
>>> But while we're there, we probably want to know what else the token
>>> is for, since this service will probably know that, so let's add in
>>> the "scope" and "client_id" and whatever other meta-information we
>>> have about the token. If this endpoint doesn't have that information?
>>> Well then, I guess it can't return it. So we need to make sure to be
>>> flexible about that while we define a common core set of semantics.
>>> Flexibility like that is very powerful and could be used in a variety
>>> of protocols and deployments across domains and vendors.
>>>
>>> You know, this idea is sounding better and better. In fact, I'll do
>>> you one better. I think this is such a fantastic idea that I wrote it
>>> all down in RFC format:
>>>
>>>>>     *Cc:* <[email-masked] <mailto:[email-masked]>>; George
>>>>>     Fletcher; Phil Hunt
>>>>>     Decoding a token with a specific format wouldn't tell you
>>>>>     whether the token is still live: it could have been revoked
>>>>>     before its expiration.
>>>>>
>>>>>     I realize that might or might not be practical in some cases,
>>>>>     but I haven’t heard that alternative discussed, so I thought
>>>>>     I’d bring it up.
>>>>>
>>>>>
>>>>>     I also second Phil’s comment that it would be good to
>>>>>     understand the use cases that this is intended to solve before
>>>>>     embarking on a particular solution path.
>>>>>
>>>>>
>>>>>     -- Mike
>>>>>
>>>>>
>>>>>     We also have a use case where the AS is provided by a partner
>>>>>     and the RS is provided by AOL. Being able to have a
>>>>>     standardized way of validating and getting data about the token
>>>>>     from the AS would make our implementation much simpler as we
>>>>>     can use the same mechanism for all Authorization Servers and
>>>>>         Is it driven by scenarios where AS and resource are
>>>>>         separate domains? Or may this be only of interest to
>>>>>         specific protocols like UMA?
>>>>>
>>>>>
>>>>>         From a technique principle, the draft is important and
>>>>>         sound. I am just not there yet on the reasons for an
>>>>>         interoperable standard.
>>>>>
>>>>>
>>>>>         Phil
>>>>>
>>>>>
>>>>>         On Jul 28, 2014, at 17:00, Thomas Broyer
>>>>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>

---

From: John Bradley <[email-masked]>
Date: Wed, 30 Jul 2014 07:42:00 -0400

This request for only those not at the F2F to add to the hum has gone a bit off the rails. 

For those not in the room there was discussion that the draft needed a method to deal with:
- Multiple AS
- Supporting the PoP specs
- stopping clients or other interceptors of the token from introspecting it.

Justin stated that his implementation already had a number of those features. 

I offered to help get those into the spec as part of my support for making this a WG item. 

Yes if AS and RS are monolithic and there is only one software vendor, then this is not needed. 

On the other hand there is evidence that is not the case. 

John B. 

Sent from my iPad

> On Jul 30, 2014, at 3:45 AM, Sergey Beryozkin <[email-masked]> wrote:
> 
> +1.
> 
> I've understood from what Justin said the idea is to introduce a standard way for RS to communicate to AS about the tokens issued by the AS. I think it is a good idea, I'd only not focus on the RS-to-3rd party AS communications because it complicates it a bit.
> 
> Clearly it would be of help to implementers of OAuth2 filters protecting RS, having a new lengthy process to collect the cases seems to be a very administrative idea to me
> 
> Thanks, Sergey
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 30 Jul 2014 14:51:06 +0300

> This request for only those not at the F2F to add to the hum has gone a bit off the rails.
Meaning you see too much feedback, is it bad, even if some of it may be 
off topic ?
> Yes if AS and RS are monolithic and there is only one software vendor, then this is not needed.
Why not ? What is wrong with standardizing an introspection process 
which even RS & AS from the same vendor may want to use as opposed to 
every vendor inventing its own protocol ?

This is why I thought focusing on the RS to 3rd party only diverts from 
the idea which I 'read' in the thread (may be I'm wrong), i.e, 
standardizing on the RS-to-AS communication, which may not have been 
considered,

Cheers, Sergey

---

From: John Bradley <[email-masked]>
Date: Wed, 30 Jul 2014 07:59:56 -0400

No,  that those of us who we're fallowing the instructions not to comment if our hum was recorded in the room, should not hold back given the nature of the thread has changed. 

It was also an indication to the char that the original intent of the thread to judge consensus is impacted by some people who previously hummed piling on the thread. 

I am more than fine with discussion.  It probably should have been a different thread though.

John B. 
Sent from my iPhone

> On Jul 30, 2014, at 7:51 AM, Sergey Beryozkin <[email-masked]> wrote:
> 
> Meaning you see too much feedback, is it bad, even if some of it may be off topic ?
> Why not ? What is wrong with standardizing an introspection process which even RS & AS from the same vendor may want to use as opposed to every vendor inventing its own protocol ?
> 
> This is why I thought focusing on the RS to 3rd party only diverts from the idea which I 'read' in the thread (may be I'm wrong), i.e, standardizing on the RS-to-AS communication, which may not have been considered,
> 
> Cheers, Sergey
> 
>>

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 30 Jul 2014 15:05:20 +0300

Hi John
> It was also an indication to the char that the original intent of the thread to judge consensus is impacted by some people who previously hummed piling on the thread.
I think I understand, thanks for the clarifications, though it appears 
to be more subtle to me that various OAuth2 technical ambiguities :-)
> I am more than fine with discussion.  It probably should have been a different thread though.
Thanks, sorry for the noise anyway

Sergey

---

From: George Fletcher <[email-masked]>
Date: Wed, 30 Jul 2014 09:29:44 -0400

Actually, I view this in a much simpler way. In today's environment 
there is a tight coupling between AS and RS. Each deployment has to 
develop it's own mechanism for dealing with understanding tokens (even 
if the AS and RS are in the same domain).

The introspection spec solve probably 80+ percent of those tight 
coupling use cases.

As an RS, I do not want to have to write special code for every AS to 
understand their unique token or mechanism for validating tokens and I'm 
sure that every AS does not want to implement our specific token. In 
both of these cases there is a tight coupling required.

As for the privacy issues, the introspection endpoint is an OAuth2 
protected API and can enforce the presentation of an authorization token 
(RFC 6750) before responding with the token data. This allows for the 
return of pseudonymous identifiers and other privacy protecting mechanisms.

Thanks,
George

// Line feeds added for formatting purposes only :)
{
    "bit_of_a_rant" : "Since the introspection spec is not mandatory to
                       implement, I don't see why there is such concern 
over
                       it. If an AS doesn't want to implement the endpoint,
                       they don't need to. However, for those who do 
(and there
                       is a good number in this community) it solves a
                       real problem."
}

On 7/29/14, 7:44 PM, Phil Hunt wrote:
> There’s also federation cases. Federated authorization seems like a 
> different problem than federated authentication from a trust perspective.
>
> There may be some complex privacy issues involved as well. For 
> example, in many cases, the desire is to allow authz information 
> *only* the actual content owner / delegator may be intentionally 
> pseudonymous.
>
> _I would support first developing a use case document to figure out if 
> there is an appropriate pattern that can satisfy (and simplify) a 
> majority of cases._
>
> Phil
>
> @independentid
> On Jul 29, 2014, at 3:24 PM, George Fletcher <[email-masked] 
> <mailto:[email-masked]>> wrote:
>

---

From: George Fletcher <[email-masked]>
Date: Wed, 30 Jul 2014 09:32:16 -0400

Actually there is both:) There is a JWS that contains an opaque token 
from the partner AS. We "introspect" the opaque token with the partner 
at every JWS validation to ensure the authorization is still valid. This 
is a risk decisions agreed to by both parties. Obviously there are other 
ways to solve that part of the problem.

So even though there is a JWS involved, it doesn't necessarily remove 
the need for introspection.

Thanks,
George

-- 
George Fletcher <http://connect.me/gffletch>

---

From: George Fletcher <[email-masked]>
Date: Wed, 30 Jul 2014 09:37:44 -0400

+100 :)

---

From: John Bradley <[email-masked]>
Date: Wed, 30 Jul 2014 10:20:08 -0400

No worries.

Some of the people in the F2F piling on with discussion derailed  Hannes original question.
>        comments along to the list in your response to this Call for

People not in the room commenting and asking questions is expected.   People who expressed opinions in the room should avoid double counting by making it clear they hummed in the room, as our AD may not know everyone's face and name.

I don't know how I became the process monitor.   Normally I am the trouble maker.

I believe what passed for consensus in the room was that this ork is in scope for the WG and this document can serve as a starting point, but that there are things that need to be added.

I think Phil would like a use case document to flesh out peoples understanding.  Others who have been working on this longer are hesitant that doing a use case document without adopting Justin's document as a starting point, will stall the process.

We can however adopt Justin's doc and in parallel add a use case section as part of the doc or as a separate doc.

So if you were not in the F2F hum you need to express an opinion on if draft-richer-oauth-introspection-06.txt should be adopted by the WG item.

John B.
(PS I was in the room and hummed in favour of adopting this as a work item)

On Jul 30, 2014, at 8:05 AM, Sergey Beryozkin <[email-masked]> wrote:

> I think I understand, thanks for the clarifications, though it appears to be more subtle to me that various OAuth2 technical ambiguities :-)

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 30 Jul 2014 14:32:55 +0000

John this is for the people that did not hum  at the face to face and not just for the people not  at the face to face.

Sent from my Windows Phone
________________________________
From: John Bradley<mailto:[email-masked]>
Sent: ‎7/‎30/‎2014 7:20 AM
To: Sergey Beryozkin<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item

No worries.

John B.

---

From: John Bradley <[email-masked]>
Date: Wed, 30 Jul 2014 12:14:24 -0400

Interesting point.  I defer to your greater hum experience:)

On Jul 30, 2014, at 10:32 AM, Anthony Nadalin <[email-masked]> wrote:

> From: John Bradley
> To: Sergey Beryozkin

---

From: Brian Campbell <[email-masked]>
Date: Wed, 30 Jul 2014 14:24:17 -0600

Will the minutes of the meeting be made available? Those might provide
a little more context to those of us who were unable to attend.

On Wed, Jul 30, 2014 at 10:14 AM, John Bradley <[email-masked]> wrote:
> John this is for the people that did not hum  at the face to face and not
> just for the people not  at the face to face.
>
> Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token
> People not in the room commenting and asking questions is expected.   People
> who expressed opinions in the room should avoid double counting by making it
> clear they hummed in the room, as our AD may not know everyone's face and
> name.
>
> I believe what passed for consensus in the room was that this ork is in
> scope for the WG and this document can serve as a starting point, but that
> there are things that need to be added.
>
> I think Phil would like a use case document to flesh out peoples
> understanding.  Others who have been working on this longer are hesitant
> that doing a use case document without adopting Justin's document as a
> starting point, will stall the process.
>
> So if you were not in the F2F hum you need to express an opinion on if
> draft-richer-oauth-introspection-06.txt should be adopted by the WG item.
>
> John B.
>>> No,  that those of us who we're fallowing the instructions not to comment
>>> if our hum was recorded in the room, should not hold back given the nature
>>> of the thread has changed.
>>>
>>> It was also an indication to the char that the original intent of the
>>> thread to judge consensus is impacted by some people who previously hummed
>>> piling on the thread.
>>>
>> I think I understand, thanks for the clarifications, though it appears to
>> be more subtle to me that various OAuth2 technical ambiguities :-)
>>>> which even RS & AS from the same vendor may want to use as opposed to every
>>>> vendor inventing its own protocol ?
>>>>
>>>> the idea which I 'read' in the thread (may be I'm wrong), i.e, standardizing
>>>> on the RS-to-AS communication, which may not have been considered,
>>>>
>>>> Cheers, Sergey
>>>>
>>>>>
>>>>>> standard way for RS to communicate to AS about the tokens issued by the AS.
>>>>>> I think it is a good idea, I'd only not focus on the RS-to-3rd party AS
>>>>>> communications because it complicates it a bit.
>>>>>>
>>>>>> Clearly it would be of help to implementers of OAuth2 filters
>>>>>> protecting RS, having a new lengthy process to collect the cases seems to be
>>>>>> a very administrative idea to me
>>>>>>
>>>>>> Thanks, Sergey
>>>>>>
>>>>>>>>> the
>>>>>>>>>        (draft-richer-oauth-introspection-06.txt) specification as
>>>>>>>>> an
>>>>>>>>>        OAuth WG
>>>>>>>>>        work item.
>>>>>>>>>
>>>>>>>>>        please send mail to the OAuth WG list indicating your
>>>>>>>>> opinion
>>>>>>>>>        (Yes/No).
>>>>>>>>>
>>>>>>>>>        The confirmation call for adoption will last until August
>>>>>>>>> 10,
>>>>>>>>>        2014.  If