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

[Brian Campbell]

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  wrote:
> Interesting point.  I defer to your greater hum experience:)
>
> On Jul 30, 2014, at 10:32 AM, Anthony Nadalin  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.
>
> Sent from my Windows Phone
> 
> From: John Bradley
> Sent: ‎7/‎30/‎2014 7:20 AM
> To: Sergey Beryozkin
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token
> Introspection" as an OAuth Working Group Item
>
> No worries.
>
> Some of the people in the F2F piling on with discussion derailed  Hannes
> original question.
>>  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.
>
> 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  wrote:
>
>> Hi John
>> On 30/07/14 14:59, John Bradley wrote:
>>> 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 :-)
>>> I am more than fine with discussion.  It probably should have been a
>>> different thread though.
>>>
>> Thanks, sorry for the noise anyway
>>
>> Sergey
>>> John B.
>>> Sent from my iPhone
>>>
>>>> On Jul 30, 2014, at 7:51 AM, Sergey Beryozkin 
>>>> wrote:
>>>>
>>>>> On 30/07/14 14:42, John Bradley wrote:
>>>>> 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 ?
>>>>> For those not in the room there was discussion that the draft needed a
>>>>> method to deal with:
>>>>> - Multiple AS
>>>>> - Supporting the PoP specs
>>>>> - s

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

[John Bradley]

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

On Jul 30, 2014, at 10:32 AM, Anthony Nadalin  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.
> 
> Sent from my Windows Phone
> From: John Bradley
> Sent: ‎7/‎30/‎2014 7:20 AM
> To: Sergey Beryozkin
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token 
> Introspection" as an OAuth Working Group Item
> 
> No worries.
> 
> Some of the people in the F2F piling on with discussion derailed  Hannes 
> original question.
> >  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.
> 
> 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  wrote:
> 
> > Hi John
> > On 30/07/14 14:59, John Bradley wrote:
> >> 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 :-)
> >> I am more than fine with discussion.  It probably should have been a 
> >> different thread though.
> >> 
> > Thanks, sorry for the noise anyway
> > 
> > Sergey
> >> John B.
> >> Sent from my iPhone
> >> 
> >>> On Jul 30, 2014, at 7:51 AM, Sergey Beryozkin  
> >>> wrote:
> >>> 
> >>>> On 30/07/14 14:42, John Bradley wrote:
> >>>> 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 ?
> >>>> 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.
> >>>> 
> >>>&

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

[Anthony Nadalin]

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:ve7...@ve7jtb.com>
Sent: ‎7/‎30/‎2014 7:20 AM
To: Sergey Beryozkin<mailto:sberyoz...@gmail.com>
Cc: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token 
Introspection" as an OAuth Working Group Item

No worries.

Some of the people in the F2F piling on with discussion derailed  Hannes 
original question.
>  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.

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

> Hi John
> On 30/07/14 14:59, John Bradley wrote:
>> 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 :-)
>> I am more than fine with discussion.  It probably should have been a 
>> different thread though.
>>
> Thanks, sorry for the noise anyway
>
> Sergey
>> John B.
>> Sent from my iPhone
>>
>>> On Jul 30, 2014, at 7:51 AM, Sergey Beryozkin  wrote:
>>>
>>>> On 30/07/14 14:42, John Bradley wrote:
>>>> 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 ?
>>>> 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.
>>> Why not ? What is wrong with standardizing an introspection process which 
>>> even RS & AS from the same vendor may want to u

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

[John Bradley]

that is not the case.
>>>> 
>>>> John B.
>>>> 
>>>> 
>>>> Sent from my iPad
>>>> 
>>>>> On Jul 30, 2014, at 3:45 AM, Sergey Beryozkin  
>>>>> 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
>>>>> 
>>>>>> On 30/07/14 03:54, Phil Hunt wrote:
>>>>>> -100
>>>>>> 
>>>>>> Phil
>>>>>> 
>>>>>> On Jul 29, 2014, at 17:52, Justin Richer >>>>> <mailto:jric...@mit.edu>> 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
>>>>>>> 
>>>>>>> 
>>>>>>>> On 7/29/2014 8:16 PM, Mike Jones wrote:
>>>>>>>> 
>>>>>>>> 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:oauth-boun...@ietf.org] *On Behalf Of *George
>>>>>>>> Fletcher
>>>>>>>> *Sent:* Tuesday, July 29, 2014 3:25 PM
>>>>>>>> *To:* Phil Hunt; Thomas Broyer
>>>>>>>> *Cc:* oauth@ietf.org
>>>>>>>> *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
>>>>>>>> 
>>>>>>>> On 7/28/14, 8:11 PM, Phil Hunt wrote:
>>>>>>>> 
>>>>>>>>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
>>>>>>>> 

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

[George Fletcher]

+100 :)

On 7/29/14, 8:52 PM, Justin Richer 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


On 7/29/2014 8:16 PM, Mike Jones wrote:


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:oauth-boun...@ietf.org] *On Behalf Of *George 
Fletcher

*Sent:* Tuesday, July 29, 2014 3:25 PM
*To:* Phil Hunt; Thomas Broyer
*Cc:* oauth@ietf.org
*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

On 7/28/14, 8:11 PM, Phil Hunt wrote:

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 mailto:t.bro...@gmail.com>> 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
mailto:hannes.tschofe...@gmx.net>> wrote:

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


___
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
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
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth




___

OAuth mailing list

OAuth@ietf.org  <mailto:OAuth@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth



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




--
George Fletcher <http://connect.me/gffletch>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[George Fletcher]

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

On 7/29/14, 8:16 PM, Mike Jones wrote:


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:oauth-boun...@ietf.org] *On Behalf Of *George 
Fletcher

*Sent:* Tuesday, July 29, 2014 3:25 PM
*To:* Phil Hunt; Thomas Broyer
*Cc:* oauth@ietf.org
*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

On 7/28/14, 8:11 PM, Phil Hunt wrote:

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 mailto:t.bro...@gmail.com>> 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
mailto:hannes.tschofe...@gmx.net>>
wrote:

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


___
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
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
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth




___

OAuth mailing list

OAuth@ietf.org  <mailto:OAuth@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth



--
George Fletcher <http://connect.me/gffletch>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[George Fletcher]

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:

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 
phil.h...@oracle.com 



On Jul 29, 2014, at 3:24 PM, George Fletcher > 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

On 7/28/14, 8:11 PM, Phil Hunt wrote:

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 > 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 
mailto:hannes.tschofe...@gmx.net>> wrote:


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


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




--
Thomas Broyer
/tɔ.ma.bʁwa.je/ 
___
OAuth mailing list
OAuth@ietf.org 
https://www.ietf.org/mailman/listinfo/oauth



___

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

[Sergey Beryozkin]

Hi John
On 30/07/14 14:59, John Bradley wrote:

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

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


Thanks, sorry for the noise anyway

Sergey

John B.
Sent from my iPhone


On Jul 30, 2014, at 7:51 AM, Sergey Beryozkin  wrote:


On 30/07/14 14:42, John Bradley wrote:
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 ?

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.

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



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


On 30/07/14 03:54, Phil Hunt wrote:
-100

Phil

On Jul 29, 2014, at 17:52, Justin Richer mailto:jric...@mit.edu>> 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



On 7/29/2014 8:16 PM, Mike Jones wrote:

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:oauth-boun...@ietf.org] *On Behalf Of *George
Fletcher
*Sent:* Tuesday, July 29, 2014 3:25 PM
*To:* Phil Hunt; Thomas Broyer
*Cc:* oauth@ietf.org
*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

On 7/28/14, 8:11 PM, Phil Hunt wrote:

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 mailto:t.bro...@gmail.com>> wrote:

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

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

[John Bradley]

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  wrote:
> 
>> On 30/07/14 14:42, John Bradley wrote:
>> 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 ?
>> 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.
> 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
> 
>> 
>> 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  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
>>> 
>>>> On 30/07/14 03:54, Phil Hunt wrote:
>>>> -100
>>>> 
>>>> Phil
>>>> 
>>>> On Jul 29, 2014, at 17:52, Justin Richer >>> <mailto:jric...@mit.edu>> 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
>>>>> 
>>>>> 
>>>>>> On 7/29/2014 8:16 PM, Mike Jones wrote:
>>>>>> 
>>>>>> 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:oauth-boun...@ietf.org] *On Behalf Of *George
>>>>>> Fletcher
>>>>>> *Sent:* Tuesday, July 29, 2014 3:25 PM
>>>>>> *To:* Phil Hunt; Thomas Broyer
>>>>&g

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

[Sergey Beryozkin]

On 30/07/14 14:42, John Bradley wrote:

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 ?

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



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


On 30/07/14 03:54, Phil Hunt wrote:
-100

Phil

On Jul 29, 2014, at 17:52, Justin Richer mailto:jric...@mit.edu>> 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



On 7/29/2014 8:16 PM, Mike Jones wrote:

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:oauth-boun...@ietf.org] *On Behalf Of *George
Fletcher
*Sent:* Tuesday, July 29, 2014 3:25 PM
*To:* Phil Hunt; Thomas Broyer
*Cc:* oauth@ietf.org
*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

On 7/28/14, 8:11 PM, Phil Hunt wrote:

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 mailto:t.bro...@gmail.com>> 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
mailto:hannes.tschofe...@gmx.net>> wrote:

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 wor

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

[John Bradley]

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  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
> 
>> On 30/07/14 03:54, Phil Hunt wrote:
>> -100
>> 
>> Phil
>> 
>> On Jul 29, 2014, at 17:52, Justin Richer > <mailto:jric...@mit.edu>> 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
>>> 
>>> 
>>>> On 7/29/2014 8:16 PM, Mike Jones wrote:
>>>> 
>>>> 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:oauth-boun...@ietf.org] *On Behalf Of *George
>>>> Fletcher
>>>> *Sent:* Tuesday, July 29, 2014 3:25 PM
>>>> *To:* Phil Hunt; Thomas Broyer
>>>> *Cc:* oauth@ietf.org
>>>> *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
>>>> 
>>>> On 7/28/14, 8:11 PM, Phil Hunt wrote:
>>>> 
>>>>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 >>><mailto:t.bro...@gmail.com>> 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
>>>>>>><mailto

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

[Sergey Beryozkin]

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 mailto:phil.h...@oracle.com>> wrote:


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 mailto:jric...@mit.edu>> wrote:


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:

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 mailto:t.bro...@gmail.com>> 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" mailto:michael.jo...@microsoft.com>> 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:t.bro...@gmail.com
<mailto:t.bro...@gmail.com>]
    *Sent:* Tuesday, July 29, 2014 5:43 PM
    *To:* Mike Jones
*Cc:* mailto:oauth@ietf.org>>; 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"
mailto:michael.jo...@microsoft.com>> 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:oauth-boun...@ietf.org
<mailto:oauth-boun...@ietf.org>] *On Behalf Of *George Fletcher
   

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

[Sergey Beryozkin]

+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 mailto:jric...@mit.edu>> 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


On 7/29/2014 8:16 PM, Mike Jones wrote:


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:oauth-boun...@ietf.org] *On Behalf Of *George
Fletcher
*Sent:* Tuesday, July 29, 2014 3:25 PM
*To:* Phil Hunt; Thomas Broyer
*Cc:* oauth@ietf.org
*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

On 7/28/14, 8:11 PM, Phil Hunt wrote:

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 mailto:t.bro...@gmail.com>> 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
mailto:hannes.tschofe...@gmx.net>> wrote:

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


___
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
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
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth




___

OAuth mailing list

OAuth@ietf.org  <mailto:OAuth@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth



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

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

[Thomas Broyer]

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"  a écrit :

> 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  wrote:
>
> 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:
>
> 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  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"  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:t.bro...@gmail.com]
>> *Sent:* Tuesday, July 29, 2014 5:43 PM
>> *To:* Mike Jones
>> *Cc:* ; 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"  a
>> écrit :
>>

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

[Tirumaleswar Reddy (tireddy)]

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:oauth-boun...@ietf.org] On Behalf Of Justin Richer
Sent: Wednesday, July 30, 2014 6:21 AM
To: Mike Jones; Thomas Broyer
Cc: 
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token 
Introspection" as an OAuth Working Group Item

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:t.bro...@gmail.com]
Sent: Tuesday, July 29, 2014 5:43 PM
To: Mike Jones
Cc: <mailto:oauth@ietf.org>; 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" 
mailto:michael.jo...@microsoft.com>> 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:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On 
Behalf Of George Fletcher
Sent: Tuesday, July 29, 2014 3:25 PM
To: Phil Hunt; Thomas Broyer
Cc: oauth@ietf.org<mailto:oauth@ietf.org>
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
On 7/28/14, 8:11 PM, Phil Hunt wrote:
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 
mailto:t.bro...@gmail.com>> 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 
mailto:hannes.tschofe...@gmx.net>> wrote:
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


___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
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
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth




___

OAuth mailing list

OAuth@ietf.org<mailto:OAuth@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth





___

OAuth mailing list

OAuth@ietf.org<mailto:OAuth@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth

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

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

[Eve Maler]

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

On 29 Jul 2014, at 6:17 PM, Phil Hunt  wrote:

> 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  wrote:
> 
>> 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:
>>> 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  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"  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:t.bro...@gmail.com] 
>>>> Sent: Tuesday, July 29, 2014 5:43 PM
>>>> To: Mike Jones
>>>> Cc: ; 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"  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

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

[Phil Hunt]

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  wrote:
> 
> 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:
>> 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  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"  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:t.bro...@gmail.com] 
>>>> Sent: Tuesday, July 29, 2014 5:43 PM
>>>> To: Mike Jones
>>>> Cc: ; 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"  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:oauth-boun...@ietf.org] On Behalf Of George Fletcher
>>>> Sent: Tuesday, July 29, 2014 3:25 PM
>>>> To: Phil Hunt; Thomas Broyer
>>>> Cc: oauth@ietf.org
>>>> Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token 

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

[Anthony Nadalin]

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:oauth-boun...@ietf.org] On Behalf Of Justin Richer
Sent: Tuesday, July 29, 2014 6:08 PM
To: Phil Hunt; Thomas Broyer
Cc: 
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:

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:
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 
mailto:t.bro...@gmail.com>> 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" 
mailto:michael.jo...@microsoft.com>> 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:t.bro...@gmail.com<mailto:t.bro...@gmail.com>]
Sent: Tuesday, July 29, 2014 5:43 PM
To: Mike Jones
Cc: mailto:oauth@ietf.org>>; 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" 
mailto:michael.jo...@microsoft.com>> 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:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On 
Behalf Of George Fletcher
Sent: Tuesday, July 29, 2014 3:25 PM
To: Phil Hunt; Thomas Broyer
Cc: oauth@ietf.org<mailto:oauth@ietf.org>
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
On 7/28/14, 8:11 PM, Phil Hunt wrote:
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 
mailto:t.bro...@gm

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

[Justin Richer]

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:
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 <mailto:t.bro...@gmail.com>> 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" <mailto:michael.jo...@microsoft.com>> 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:t.bro...@gmail.com
<mailto:t.bro...@gmail.com>]
*Sent:* Tuesday, July 29, 2014 5:43 PM
    *To:* Mike Jones
    *Cc:* mailto:oauth@ietf.org>>; 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" mailto:michael.jo...@microsoft.com>> 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:oauth-boun...@ietf.org
<mailto:oauth-boun...@ietf.org>] *On Behalf Of *George Fletcher
    *Sent:* Tuesday, July 29, 2014 3:25 PM
*To:* Phil Hunt; Thomas Broyer
*Cc:* oauth@ietf.org <mailto:oauth@ietf.org>
*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

On 7/28/14, 8:11 PM, Phil Hunt wrote:

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 mailto:t.bro...@gmail.com>> 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
mailto:hannes.tschofe...@gmx.net>> wrote:

Hi all,

during the IETF #90 OAuth WG meeting, there was strong
   

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

[Phil Hunt]

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  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"  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:t.bro...@gmail.com] 
>> Sent: Tuesday, July 29, 2014 5:43 PM
>> To: Mike Jones
>> Cc: ; 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"  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:oauth-boun...@ietf.org] On Behalf Of George Fletcher
>> Sent: Tuesday, July 29, 2014 3:25 PM
>> To: Phil Hunt; Thomas Broyer
>> Cc: oauth@ietf.org
>> 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
>> 
>> On 7/28/14, 8:11 PM, Phil Hunt wrote:
>> 
>> 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  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 
>>  wrote:
>> 
>> 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
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>> 
>> 
>>  
>> 
>> -- 
>> Thomas Broyer
>> /tɔ.ma.bʁwa.je/
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Thomas Broyer]

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"  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:t.bro...@gmail.com]
> *Sent:* Tuesday, July 29, 2014 5:43 PM
> *To:* Mike Jones
> *Cc:* ; 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"  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:oauth-boun...@ietf.org] *On Behalf Of *George
> Fletcher
> *Sent:* Tuesday, July 29, 2014 3:25 PM
> *To:* Phil Hunt; Thomas Broyer
> *Cc:* oauth@ietf.org
> *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
>
> On 7/28/14, 8:11 PM, Phil Hunt wrote:
>
>  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  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 <
> hannes.tschofe...@gmx.net> wrote:
>
> 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
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>  ___
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Phil Hunt]

-100

Phil

> On Jul 29, 2014, at 17:52, Justin Richer  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
> 
> 
>> On 7/29/2014 8:16 PM, Mike Jones wrote:
>> 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:oauth-boun...@ietf.org] On Behalf Of 
>> George Fletcher
>> Sent: Tuesday, July 29, 2014 3:25 PM
>> To: Phil Hunt; Thomas Broyer
>> Cc: oauth@ietf.org
>> 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
>> 
>> On 7/28/14, 8:11 PM, Phil Hunt wrote:
>> 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  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 
>>  wrote:
>> 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
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>> 
>>  
>> -- 
>> Thomas Broyer
>> /tɔ.ma.bʁwa.je/
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>  
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Justin Richer]

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:


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:oauth-boun...@ietf.org] *On Behalf Of *George 
Fletcher

*Sent:* Tuesday, July 29, 2014 3:25 PM
*To:* Phil Hunt; Thomas Broyer
*Cc:* oauth@ietf.org
*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

On 7/28/14, 8:11 PM, Phil Hunt wrote:

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 mailto:t.bro...@gmail.com>> 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
mailto:hannes.tschofe...@gmx.net>>
wrote:

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


___
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
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
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth




___

OAuth mailing list

OAuth@ietf.org  <mailto:OAuth@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth



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


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

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

[Justin Richer]

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:t.bro...@gmail.com]
*Sent:* Tuesday, July 29, 2014 5:43 PM
*To:* Mike Jones
*Cc:* ; 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" <mailto:michael.jo...@microsoft.com>> 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:oauth-boun...@ietf.org 
<mailto:oauth-boun...@ietf.org>] *On Behalf Of *George Fletcher

*Sent:* Tuesday, July 29, 2014 3:25 PM
*To:* Phil Hunt; Thomas Broyer
*Cc:* oauth@ietf.org <mailto:oauth@ietf.org>
*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

On 7/28/14, 8:11 PM, Phil Hunt wrote:

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 mailto:t.bro...@gmail.com>> 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
mailto:hannes.tschofe...@gmx.net>>
wrote:

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


___
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
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
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth



___

OAuth mailing list

OAuth@ietf.org  <mailto:OAuth@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth



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


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

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

[Mike Jones]

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

From: Thomas Broyer [mailto:t.bro...@gmail.com]
Sent: Tuesday, July 29, 2014 5:43 PM
To: Mike Jones
Cc: ; 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" 
mailto:michael.jo...@microsoft.com>> 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:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On 
Behalf Of George Fletcher
Sent: Tuesday, July 29, 2014 3:25 PM
To: Phil Hunt; Thomas Broyer
Cc: oauth@ietf.org<mailto:oauth@ietf.org>
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
On 7/28/14, 8:11 PM, Phil Hunt wrote:
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 
mailto:t.bro...@gmail.com>> 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 
mailto:hannes.tschofe...@gmx.net>> wrote:
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


___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
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
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth



___

OAuth mailing list

OAuth@ietf.org<mailto:OAuth@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth

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

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

[Thomas Broyer]

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"  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:oauth-boun...@ietf.org] *On Behalf Of *George
> Fletcher
> *Sent:* Tuesday, July 29, 2014 3:25 PM
> *To:* Phil Hunt; Thomas Broyer
> *Cc:* oauth@ietf.org
> *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
>
> On 7/28/14, 8:11 PM, Phil Hunt wrote:
>
>  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  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 <
> hannes.tschofe...@gmx.net> wrote:
>
> 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
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>  ___
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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:oauth-boun...@ietf.org] On Behalf Of George Fletcher
Sent: Tuesday, July 29, 2014 3:25 PM
To: Phil Hunt; Thomas Broyer
Cc: oauth@ietf.org
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
On 7/28/14, 8:11 PM, Phil Hunt wrote:
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 
mailto:t.bro...@gmail.com>> 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 
mailto:hannes.tschofe...@gmx.net>> wrote:
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


___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
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
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth




___

OAuth mailing list

OAuth@ietf.org<mailto:OAuth@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth

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

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

[Phil Hunt]

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
phil.h...@oracle.com



On Jul 29, 2014, at 3:24 PM, George Fletcher  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
> 
> On 7/28/14, 8:11 PM, Phil Hunt wrote:
>> 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  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 
>>>  wrote:
>>> 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
>>> 
>>> 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Thomas Broyer
>>> /tɔ.ma.bʁwa.je/
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 

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

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

[George Fletcher]

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

On 7/28/14, 8:11 PM, Phil Hunt wrote:

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 > 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 
mailto:hannes.tschofe...@gmx.net>> wrote:


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


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




--
Thomas Broyer
/t?.ma.b?wa.je/ 
___
OAuth mailing list
OAuth@ietf.org 
https://www.ietf.org/mailman/listinfo/oauth



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


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

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

[Thomas Broyer]

On Tue, Jul 29, 2014 at 10:41 PM, Phil Hunt  wrote:

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

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.

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Phil Hunt]

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  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
> 
>> 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.
>> 
>> 
>> On Tuesday, July 29, 2014 2:56 AM, Paul Madsen  wrote:
>> 
>> 
>> 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  wrote:
>> 
>>> 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
>>> phil.h...@oracle.com
>>> 
>>> 
>>> 
 On Jul 28, 2014, at 5:39 PM, Justin Richer
   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
 
> On 7/28/2014 8:11 PM, Phil Hunt wrote:
> 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  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 
>>  wrote:
>> 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-intro

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

[Eve Maler]

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  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
> 
> 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.
>> 
>> 
>> On Tuesday, July 29, 2014 2:56 AM, Paul Madsen  wrote:
>> 
>> 
>> 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  wrote:
>> 
>>> 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
>>> phil.h...@oracle.com
>>> 
>>> 
>>> 
>>> On Jul 28, 2014, at 5:39 PM, Justin Richer  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
 
 On 7/28/2014 8:11 PM, Phil Hunt wrote:
> 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  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 
>>  wrote:
>> 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 opini

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

[Justin Richer]

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.



On Tuesday, July 29, 2014 2:56 AM, Paul Madsen  
wrote:



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


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 
phil.h...@oracle.com 



On Jul 28, 2014, at 5:39 PM, Justin Richer > 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

On 7/28/2014 8:11 PM, Phil Hunt wrote:

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 > 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 
mailto:hannes.tschofe...@gmx.net>> wrote:


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


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




--
Thomas Broyer
/t?.ma.b?wa.je/ 
___

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

[Bill Mills]

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


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


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.comphil.h...@oracle.com
>
>
>
>
>On Jul 28, 2014, at 5:39 PM, Justin Richer  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
>>
>>On 7/28/2014 8:11 PM, Phil Hunt wrote:
>>
>>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  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 
 wrote:

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
>
>
>___
>OAuth mailing list
>OAuth@ietf.org
>https://www.ietf.org/mailman/listinfo/oauth
>
>




-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ 
>>>___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

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

[Justin Richer]

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:oauth-boun...@ietf.org] *On Behalf Of *Paul Madsen
*Sent:* Tuesday, July 29, 2014 2:48 AM
*To:* Phil Hunt
*Cc:* oauth@ietf.org
*Subject:* Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth 
Token Introspection" as an OAuth Working Group Item


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 <mailto:phil.h...@oracle.com>> wrote:


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

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

[Mike Jones]

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:oauth-boun...@ietf.org] On Behalf Of Paul Madsen
Sent: Tuesday, July 29, 2014 2:48 AM
To: Phil Hunt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token 
Introspection" as an OAuth Working Group Item

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 
mailto:phil.h...@oracle.com>> wrote:
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<http://www.independentid.com>
phil.h...@oracle.com<mailto:phil.h...@oracle.com>



On Jul 28, 2014, at 5:39 PM, Justin Richer 
mailto:jric...@mit.edu>> 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

On 7/28/2014 8:11 PM, Phil Hunt wrote:
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 
mailto:t.bro...@gmail.com>> 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 
mailto:hannes.tschofe...@gmx.net>> wrote:
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 fo

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

[Paul Madsen]

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  wrote:
> 
> 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
> phil.h...@oracle.com
> 
> 
> 
>> On Jul 28, 2014, at 5:39 PM, Justin Richer  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
>> 
>>> On 7/28/2014 8:11 PM, Phil Hunt wrote:
>>> 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  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 
  wrote:
> 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
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
 
 
 
 -- 
 Thomas Broyer
 /tɔ.ma.bʁwa.je/
 ___
 OAuth mailing list
 OAuth@ietf.org
 https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mark Dobrinic]

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

On 29/07/14 03:23, Justin Richer wrote:
> 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.
>>
>> 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 
>> phil.h...@oracle.com 
>>
>>
>>
>> On Jul 28, 2014, at 5:39 PM, Justin Richer > > 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
>>>
>>> On 7/28/2014 8:11 PM, Phil Hunt wrote:
 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 >>> 

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

[Tirumaleswar Reddy (tireddy)]

+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:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
> Sent: Monday, July 28, 2014 11:03 PM
> To: oauth@ietf.org
> 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:
> 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

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

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

[Justin Richer]

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.


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 
phil.h...@oracle.com 



On Jul 28, 2014, at 5:39 PM, Justin Richer > 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

On 7/28/2014 8:11 PM, Phil Hunt wrote:

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 > 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 
mailto:hannes.tschofe...@gmx.net>> wrote:


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 yo

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

[Thomas Broyer]

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

> 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  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 <
> hannes.tschofe...@gmx.net> wrote:
>
>> 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
>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
>
> --
> Thomas Broyer
> /tɔ.ma.bʁwa.je/ 
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>


-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Phil Hunt]

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
phil.h...@oracle.com



On Jul 28, 2014, at 5:39 PM, Justin Richer  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
> 
> On 7/28/2014 8:11 PM, Phil Hunt wrote:
>> 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  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 
>>>  wrote:
>>> 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
>>> 
>>> 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Thomas Broyer
>>> /tɔ.ma.bʁwa.je/
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

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

[Justin Richer]

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:

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 > 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 
mailto:hannes.tschofe...@gmx.net>> wrote:


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


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




--
Thomas Broyer
/t?.ma.b?wa.je/ 
___
OAuth mailing list
OAuth@ietf.org 
https://www.ietf.org/mailman/listinfo/oauth



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


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

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

[Phil Hunt]

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  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 
>>  wrote:
>> 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
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> 
> -- 
> Thomas Broyer
> /tɔ.ma.bʁwa.je/
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Thomas Broyer]

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 <
hannes.tschofe...@gmx.net> wrote:

> 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
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>


-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Bill Mills]

+1 adoption


On Monday, July 28, 2014 11:41 AM, Hannes Tschofenig 
 wrote:
 


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

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

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

[Eve Maler]

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

> 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
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


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

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