Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth Token Introspection as an OAuth Working Group Item
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 phil.h...@oracle.com 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 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 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 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:* 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 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
Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth Token Introspection as an OAuth Working Group Item
+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 jric...@mit.edu 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 t.bro...@gmail.com 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 hannes.tschofe...@gmx.net 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
Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth Token Introspection as an OAuth Working Group Item
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 phil.h...@oracle.com
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 jric...@mit.edu
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 t.bro...@gmail.com
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 michael.jo...@microsoft.com
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:* oauth@ietf.org 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
michael.jo...@microsoft.com
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
Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth Token Introspection as an OAuth Working Group Item
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 sberyoz...@gmail.com 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 jric...@mit.edu 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 t.bro...@gmail.com 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 hannes.tschofe...@gmx.net 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
Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth Token Introspection as an OAuth Working Group Item
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 sberyoz...@gmail.com 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 jric...@mit.edu 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 t.bro...@gmail.com 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 hannes.tschofe...@gmx.net 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
Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth Token Introspection as an OAuth Working Group Item
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 sberyoz...@gmail.com 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 sberyoz...@gmail.com 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 jric...@mit.edu 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 t.bro...@gmail.com 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 hannes.tschofe...@gmx.net
Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth Token Introspection as an OAuth Working Group Item
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 sberyoz...@gmail.com 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 sberyoz...@gmail.com 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 jric...@mit.edu 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 t.bro...@gmail.com mailto:t.bro...@gmail.com wrote: Yes. This spec is of special interest to the platform we're building for http://www.oasis
Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth Token Introspection as an OAuth Working Group Item
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 http://www.independentid.com
phil.h...@oracle.com mailto:phil.h...@oracle.com
On Jul 29, 2014, at 3:24 PM, George Fletcher gffle...@aol.com
mailto:gffle...@aol.com 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 t.bro...@gmail.com
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
hannes.tschofe...@gmx.net 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
Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth Token Introspection as an OAuth Working Group Item
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 t.bro...@gmail.com 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 hannes.tschofe...@gmx.net 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
+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 t.bro...@gmail.com 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 hannes.tschofe...@gmx.net 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
...@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 t.bro...@gmail.com 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 hannes.tschofe...@gmx.net 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth smime.p7s Description: S/MIME cryptographic signature ___ 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 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 Bradleymailto:ve7...@ve7jtb.com Sent: 7/30/2014 7:20 AM To: Sergey Beryozkinmailto:sberyoz...@gmail.com Cc: oauth@ietf.orgmailto: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 sberyoz...@gmail.com 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 sberyoz...@gmail.com 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 sberyoz...@gmail.com 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
Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth Token Introspection as an OAuth Working Group Item
Interesting point. I defer to your greater hum experience:) On Jul 30, 2014, at 10:32 AM, Anthony Nadalin tony...@microsoft.com 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 sberyoz...@gmail.com 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 sberyoz...@gmail.com 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 sberyoz
Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth Token Introspection as an OAuth Working Group Item
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 ve7...@ve7jtb.com wrote: Interesting point. I defer to your greater hum experience:) On Jul 30, 2014, at 10:32 AM, Anthony Nadalin tony...@microsoft.com 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 sberyoz...@gmail.com 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 sberyoz...@gmail.com 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
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 t.bro...@gmail.com 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 hannes.tschofe...@gmx.net 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 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
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 t.bro...@gmail.commailto: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 hannes.tschofe...@gmx.netmailto: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.orgmailto: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.orgmailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.orgmailto: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
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 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 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 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 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
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: 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 michael.jo...@microsoft.commailto: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.orgmailto: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.orgmailto: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 t.bro...@gmail.commailto: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 hannes.tschofe...@gmx.netmailto: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.orgmailto: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.orgmailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.orgmailto: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
-100 Phil On Jul 29, 2014, at 17:52, Justin Richer 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 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 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
Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth Token Introspection as an OAuth Working Group Item
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 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:* 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 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 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 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 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
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 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 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: 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 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 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 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 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
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 t.bro...@gmail.com
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 michael.jo...@microsoft.com
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:* oauth@ietf.org 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 michael.jo...@microsoft.com
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 t.bro...@gmail.com
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
hannes.tschofe...@gmx.net
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
Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth Token Introspection as an OAuth Working Group Item
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: oauth@ietf.org
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
t.bro...@gmail.commailto: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
michael.jo...@microsoft.commailto: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.commailto:t.bro...@gmail.com]
Sent: Tuesday, July 29, 2014 5:43 PM
To: Mike Jones
Cc: oauth@ietf.orgmailto: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
michael.jo...@microsoft.commailto: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.orgmailto: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.orgmailto: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
t.bro...@gmail.commailto:t.bro...@gmail.com wrote:
Yes. This spec is of special interest to the platform we're building
Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth Token Introspection as an OAuth Working Group Item
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 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 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 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: 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 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 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 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
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 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 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 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 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: 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 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 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
Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth Token Introspection as an OAuth Working Group Item
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: oauth@ietf.org 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: oauth@ietf.orgmailto: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 michael.jo...@microsoft.commailto: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.orgmailto: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.orgmailto: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 t.bro...@gmail.commailto: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 hannes.tschofe...@gmx.netmailto: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.orgmailto: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.orgmailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.orgmailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.orgmailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[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 signature.asc Description: OpenPGP digital signature ___ 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
+1 adoption On Monday, July 28, 2014 11:41 AM, 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___ 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
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
Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth Token Introspection as an OAuth Working Group Item
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 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 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
Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth Token Introspection as an OAuth Working Group Item
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 t.bro...@gmail.com 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 hannes.tschofe...@gmx.net 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 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
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 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 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 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
Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth Token Introspection as an OAuth Working Group Item
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 http://www.independentid.com phil.h...@oracle.com mailto:phil.h...@oracle.com On Jul 28, 2014, at 5:39 PM, Justin Richer jric...@mit.edu 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 t.bro...@gmail.com 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 hannes.tschofe...@gmx.net 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,
