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 Jon
Hello,
I have a question. Is there any standardized specification about
error responses from protected resource endpoints?
"RFC 6749, 7.2. Error Response" says "the specifics of such error
responses are beyond the scope of this specification", but I'm
wondering if OAuth WG has done something for
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
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 prep
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 w
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
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
Try it where? When you're the RS trying to determine whether you should
accept the token or reject it?
Le 30 juil. 2014 02:49, "Mike Jones" a écrit :
> Yes, but that’s the simplest thing to determine – try the token and see
> whether it works or not.
>
>
>
> *From:* Thomas Broyer [mailto:t.bro..
-100
Phil
> On Jul 29, 2014, at 17:52, Justin Richer wrote:
>
> Reading through this thread, it appears very clear to me that the use cases
> are very well established by a number of existing implementers who want to
> work together to build a common standard. I see no reason to delay the wor
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
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, 20
Yes, but that’s the simplest thing to determine – try the token and see whether
it works or not.
From: Thomas Broyer [mailto:t.bro...@gmail.com]
Sent: Tuesday, July 29, 2014 5:43 PM
To: Mike Jones
Cc: ; George Fletcher; Phil Hunt
Subject: RE: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth T
Decoding a token with a specific format wouldn't tell you whether the token
is still live: it could have been revoked before its expiration.
Le 30 juil. 2014 02:16, "Mike Jones" a écrit :
> Did you consider standardizing the access token format within that
> deployment so all the parties that ne
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 i
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 fe
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
On Tue, Jul 29, 2014 at 10:41 PM, Phil Hunt wrote:
> Making everything optional achieves no benefits, you just end up with a
> complex set of options and no inter op.
>
> We had the same issue with dyn reg.
>
> I prefer to first get agreement on use case.
>
> What are the questions a caller can a
Making everything optional achieves no benefits, you just end up with a complex
set of options and no inter op.
We had the same issue with dyn reg.
I prefer to first get agreement on use case.
What are the questions a caller can ask and what form of responses are
available.
Should this be
Agreed on this point too, and also wanted to point out that the UMA usage of
token introspection calls out to Justin's latest draft and formally profiles
it, which we found easy to do. UMA has a mandatory-to-implement token format
but also an extensible framework for defining whatever format sui
Agreed on this point -- which is why the only MTI bit in the individual
draft is "active", which is whether or not the token was any good to
begin with. There are a set of claims with defined semantics but all are
optional, and the list is extensible. I think in practice we'll see
people settle
This is exactly the same problem space as webfinger, you want to know something
about a user and there's a useful set of information you might reasonably
query, but in the end the server may have it's own schema of data it returns.
There won't be a single schema that fits all use cases, Any giv
I disagree with this position and think it's vital to standardize a
return structure and a common set of return values -- and that this work
would be rather pointless without it. Mike, I think you might be
thinking in terms of introspection simply unpacking what's already
contained inside the t
As I see it, there are two different kinds of standardization for introspection
that could occur. One is defining a standard endpoint for doing introspection
on an access token and possibly refresh token. The other is defining standard
contents to be returned from the introspection.
I’m skept
Standardized Introspection will be valuable in NAPPS, where the AS and RS may
be in different policy domains.
Even for single policy domains, there are enterprise scenarios where the RS is
from a different vendor than the AS, such as when an API gateway validates
tokens issued by an 'IdP' . We'
Just some way I could look at this discussion:
One way to separate an AS and an RS is specified by UMA, so for UMA it
is required to have a standardized Token Introspection feature.
If there are no other uses for separating AS/RS, then UMA would be the
place for standardizing Token Introspection.
25 matches
Mail list logo
