Once again, you may want to look at the UMA core I-D to see how it defines an
AS/RS interface:
http://tools.ietf.org/html/draft-hardjono-oauth-umacore-04
(see particularly Section 3.3)
It uses what is by now a very common token introspection pattern to have the RS
get the AS's crucial help in validating the token that was presented to it. UMA
has a mandatory-to-implement token profile called bearer, which treats the
token introspection endpoint as a run-time way to get the content associated
with the token blob. Obviously, what's returned from that call is currently
UMA-specific (and in fact this class of profiles is called UMA token
profiles). Note that the call to the token introspection endpoint must be
accompanied by an OAuth token in the header because the endpoint is
OAuth-protected. (Yes, it's turtles all the way down...) We haven't yet defined
an UMA JWT token profile, but that's the next logical step.
This type of introspection functionality could be called a narrow definition of
the AS/RS interface requirement. To make it possible to have the AS and RS live
in completely separate domains potentially controlled by different parties (a
broad definition), a number of other elements would ultimately be required.
This is where UMA's entire protection API may be interesting to look at,
since it has been demonstrated to apply to typical OAuth use cases (single
resource owner) as well as access management use cases (resource owner and
requesting party are different).
Eve
On 19 Apr 2012, at 11:31 AM, Torsten Lodderstedt wrote:
Hi Justin,
In my opinion, the OpenID Connect introspection/checkid endpoint is a
convenience function for clients (not resource servers) unable to decrypt id
tokens and validate their signatures. I'm not convinced this function is
needed, that's why I proposed to drop it.
The AS-PR endpoint servers a different purpose, as it allows to implement
handle-based token designs. The AS just creates simple token (e.g. a random
number), which is very small and does not need to be encrypted or signed.
This might result in simple designs. On the other hand, the PR needs to
lookup authz data as part of the request implementation, which might have a
negative impact on performance and scalability. That's where self-contained
tokens, such as JWT have their merits.
I don't think one would combine self-contained tokens with an AS-PR endpoint.
Or is this the case in any existing implementations?
The point I wanted to make is: no matter how the resource server acquires
authz data (as token content/JWT or via request to another AS-PR endpoint),
the authz data will be the same. And as part of the JWT standardization, we
will identify this data and specify a JSON format to represent it. The same
representation could be used at the AS-PR endpoint as well.
regards,
Torsten.
Am 18.04.2012 22:23, schrieb Justin Richer:
I think we might be crossing wires about input to the token introspection
endpoint vs. output from it.
In OpenID Connect, you send a JWT in, and get back a JSON object that
represents the Claims bit of the JWT.
In our implementation (and I think both Ping and AOL's), you send in an
arbitrary token (with no proscribed format) and get back a JSON object with
different pieces in it. Ours included a list of scopes and an expiration
timestamp, others did different things, like audience and issuer, as part of
the return.
The point I was trying to make is that the information returned from the
AS-PR interface isn't necessarily embedded inside of the token used to call
that interface. In OpenID Connect, it is, and the CheckID endpoint just
unwraps the JWT for you. In the larger case, what's really going on is that
the PR presents a token that it's not sure what it's good for and gets back
something that answers that question. Since a JWT Claims section can be an
arbitrary JSON object (for all intents and purposes), you could use a JWT as
the output of the introspection endpoint as well.
-- Justin
On 04/18/2012 04:10 PM, Torsten Lodderstedt wrote:
Hi Justin,
I refered to the data format used at the AS-PR interface. According to your
description, you use JSON objects there. What data does such an object
contain? Is this any different from a JSON Web Token (leaving aside digital
signatures and encryption)?
regards,
Torsten.
Am 18.04.2012 22:01, schrieb Justin Richer:
Not all implementations in the field that do this are using JWTs as the
tokens. Ours in particular used a random blob with no structured
information in it. The endpoint returned a JSON object.
-- Justin
On 04/18/2012 03:53 PM, Torsten Lodderstedt wrote:
Hi all,
is there enough experience in the field with such an interface to
standardize it?
I would expect such an endpoint to return the same payload, which is
carried in a JSON Web Token. So once we designed the JSON Web Tokens
