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 <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"
(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 <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
Eve Maler http://www.xmlgrrl.com/blog
+1 425 345 6756 http://www.twitter.com/xmlgrrl
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
