Interesting point. I defer to your greater hum experience:) On Jul 30, 2014, at 10:32 AM, Anthony Nadalin <[email protected]> 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: [email protected] > 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 <[email protected]> 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 <[email protected]> > >>> 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 <[email protected]> > >>>>> 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 <[email protected] > >>>>>> <mailto:[email protected]>> 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:[email protected]] *On Behalf Of *George > >>>>>>>> Fletcher > >>>>>>>> *Sent:* Tuesday, July 29, 2014 3:25 PM > >>>>>>>> *To:* Phil Hunt; Thomas Broyer > >>>>>>>> *Cc:* [email protected] > >>>>>>>> *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 <[email protected] > >>>>>>>> <mailto:[email protected]>> wrote: > >>>>>>>> > >>>>>>>> Yes. This spec is of special interest to the platform we're > >>>>>>>> building for http://www.oasis-eu.org/ > >>>>>>>> > >>>>>>>> On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig > >>>>>>>> <[email protected] > >>>>>>>> <mailto:[email protected]>> 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 > >>>>>>>> [email protected] <mailto:[email protected]> > >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Thomas Broyer > >>>>>>>> /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> OAuth mailing list > >>>>>>>> [email protected] <mailto:[email protected]> > >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> > >>>>>>>> OAuth mailing list > >>>>>>>> > >>>>>>>> [email protected] <mailto:[email protected]> > >>>>>>>> > >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> OAuth mailing list > >>>>>>>> [email protected] > >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> OAuth mailing list > >>>>>> [email protected] > >>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>> > >>>>> _______________________________________________ > >>>>> OAuth mailing list > >>>>> [email protected] > >>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
