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

Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Symmetric Proof of Posession for Code Extension" as an OAuth Working Group Item

[Phil Hunt]

+1

Phil

@independentid
www.independentid.com
phil.h...@oracle.com



On Jul 30, 2014, at 7:15 AM, George Fletcher  wrote:

> Yes, I support add this as a WG work item.
> 
> On 7/28/14, 1:33 PM, Hannes Tschofenig wrote:
>> Hi all,
>> 
>> during the IETF #90 OAuth WG meeting, there was strong consensus in
>> adopting the "OAuth Symmetric Proof of Posession for Code Extension"
>> (draft-sakimura-oauth-tcse-03.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-sakimura-oauth-tcse/
>> 
>> 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

___
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

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

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

 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:

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

[John Bradley]

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

Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Symmetric Proof of Posession for Code Extension" as an OAuth Working Group Item

[George Fletcher]

Yes, I support add this as a WG work item.

On 7/28/14, 1:33 PM, Hannes Tschofenig wrote:

Hi all,

during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Symmetric Proof of Posession for Code Extension"
(draft-sakimura-oauth-tcse-03.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-sakimura-oauth-tcse/

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] Standardized error responses from protected resource endpoints

[Takahiko Kawasaki]

Thank you very much. It is the specification for token_type=bearer
but really useful. I'm ashamed of having forgotten the content of
RFC 6750 although I had read it once before.

Best Regards,
Takahiko Kawasaki

2014-07-30 21:23 GMT+09:00 Brian Campbell :
> Take a look at RFC 6750 "The OAuth 2.0 Authorization Framework: Bearer
> Token Usage" - particularly section 3:
> http://tools.ietf.org/html/rfc6750#section-3 which describes using the
> "WWW-Authenticate" response header field in response to a request with
> an invalid/insufficient/missing/etc token.
>
> On Tue, Jul 29, 2014 at 8:10 PM, Takahiko Kawasaki  wrote:
>> Hello,
>>
>> I have a question. Is there any standardized specification about
>> error responses from protected resource endpoints?
>>
>> "RFC 6749, 7.2. Error Response" says "the specifics of such error
>> responses are beyond the scope of this specification", but I'm
>> wondering if OAuth WG has done something for that.
>>
>> >From error responses, I'd like to know information about:
>>
>>   (1) Usability (active or expired? (or not exist?))
>>   (2) Refreshability (associated usable refresh token exists?)
>>   (3) Sufficiency (usable but lacking necessary permissions?)
>>
>> For example, I'm expecting an error response like below with
>> "400 Bad Request" or "403 Forbidden".
>>
>>   {
>> "error":"...",
>> "error_description":"...",
>> "error_uri":"...",
>> "usable": true,
>> "refreshable": true,
>> "sufficient": false
>>   }
>>
>>
>> Best Regards,
>> Takahiko Kawasaki
>>
>> ___
>> 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]

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




--
George Fletcher 
___
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 
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



--
George Fletcher 
___
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] Standardized error responses from protected resource endpoints

[Brian Campbell]

Take a look at RFC 6750 "The OAuth 2.0 Authorization Framework: Bearer
Token Usage" - particularly section 3:
http://tools.ietf.org/html/rfc6750#section-3 which describes using the
"WWW-Authenticate" response header field in response to a request with
an invalid/insufficient/missing/etc token.

On Tue, Jul 29, 2014 at 8:10 PM, Takahiko Kawasaki  wrote:
> Hello,
>
> I have a question. Is there any standardized specification about
> error responses from protected resource endpoints?
>
> "RFC 6749, 7.2. Error Response" says "the specifics of such error
> responses are beyond the scope of this specification", but I'm
> wondering if OAuth WG has done something for that.
>
> >From error responses, I'd like to know information about:
>
>   (1) Usability (active or expired? (or not exist?))
>   (2) Refreshability (associated usable refresh token exists?)
>   (3) Sufficiency (usable but lacking necessary permissions?)
>
> For example, I'm expecting an error response like below with
> "400 Bad Request" or "403 Forbidden".
>
>   {
> "error":"...",
> "error_description":"...",
> "error_uri":"...",
> "usable": true,
> "refreshable": true,
> "sufficient": false
>   }
>
>
> Best Regards,
> Takahiko Kawasaki
>
> ___
> 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

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

On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig
 

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

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 work
item,
please send mail to the OAuth WG list indicating your

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

Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Symmetric Proof of Posession for Code Extension" as an OAuth Working Group Item

[Naveen Agarwal]

Yes, I support WG taking this on.


On Mon, Jul 28, 2014 at 11:57 AM, Paul Madsen  wrote:

>  I support the WG taking this on
>
>  On 7/28/14, 1:33 PM, Hannes Tschofenig wrote:
>
> Hi all,
>
> during the IETF #90 OAuth WG meeting, there was strong consensus in
> adopting the "OAuth Symmetric Proof of Posession for Code Extension"
> (draft-sakimura-oauth-tcse-03.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-sakimura-oauth-tcse/
>
> 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 listOAuth@ietf.orghttps://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

[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
,
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
]
*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
] *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 Toke

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



___
OA

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