Nothing says you need to pack the same information inside the JWT that
you return from introspection. In our specific case, we don't put scopes
or client IDs inside the JWT, just basic signature/identifier type
stuff, so you need to call introspection to get back this other
information. But the information inside the JWT includes an "iss" claim
which the client can use to figure out *which* introspection endpoint to
call.
This is just one of many different ways you could handle multiple AS at
a single resource, and so it's definitely orthogonal to the basic
introspection concept.
-- Justin
On 12/2/2014 6:38 PM, Phil Hunt wrote:
I am confused. Why would you call the introspection endpoint if you
were not expecting new information to be disclosed?
Phil
On Dec 2, 2014, at 14:26, Richer, Justin P. <jric...@mitre.org
<mailto:jric...@mitre.org>> wrote:
I agree that there's some use in this (and in fact I've deployed a
version that uses a signed JWT to indicate its authorization server),
but it should remain outside the scope of this spec. It's a service
discovery problem, it's orthogonal.
-- Justin
On Dec 2, 2014, at 5:13 PM, John Bradley <ve7...@ve7jtb.com
<mailto:ve7...@ve7jtb.com>> wrote:
Yes, but unless there is something new the introspection endpoint
in UMA is tied to the resource.
In some cases having the token indicate the introspection endpoint
may be useful.
John B.
Sent from my iPhone
On Dec 2, 2014, at 10:02 PM, Eve Maler <e...@xmlgrrl.com
<mailto:e...@xmlgrrl.com>> wrote:
FWIW, UMA goes ahead and standardizes a good deal about the trust
establishment between the RS and the AS, and (of course) profiles
and wraps the token introspection spec as part of the resulting
"authorization API" that the AS presents to the RS. A big part of
the motivation for this is to support an n:n relationship between
AS and RS entities.
EVe
On 2 Dec 2014, at 12:14 PM, John Bradley <ve7...@ve7jtb.com
<mailto:ve7...@ve7jtb.com>> wrote:
Many of the proprietary introspection protocols in use return
scope, role or other meta data for the RS to make its access
policy decision on.
One of the reasons for using opaque tokens rather than JWT is to
prevent leakage of that info.
Making authentication to the introspection endpoint a MUST if
additional attributes are present is OK, I might even be inclined
to say that authentication of some sort is always required, but
that might be going a bit far for some use cases.
We have a lot of proprietary ways to do this from IBM, Layer 7,
Ping etc. It would be nice if we could standardize it.
Precluding other attributes would not be helpful for adoption.
One issue that we haven't addressed in this spec is what happens
if there are multiple AS for the RS and how it would decide what
introspection endpoint to use.
Perhaps that needs to be a extension, leaving this for the simple
case.
However having more than on e AS per RS is not as unusual as it
once was in larger environments.
John B.
On Dec 2, 2014, at 4:56 PM, Richer, Justin P. <jric...@mitre.org
<mailto:jric...@mitre.org>> wrote:
Agreed, which is why we've got space for the "sub" and "user_id"
fields but not anything else about the user, and we've got a
privacy considerations section for dealing with that. If you can
help make the wording on that section stronger, I'd appreciate it.
-- Justin
On Dec 2, 2014, at 2:25 PM, Bill Mills <wmills_92...@yahoo.com
<mailto:wmills_92...@yahoo.com>> wrote:
If introspection returns any other user data beyond what is
strictly required to validate the token based solely on
possession of the public part it would be a mistake.
On Tuesday, December 2, 2014 11:13 AM, "Richer, Justin P."
<jric...@mitre.org <mailto:jric...@mitre.org>> wrote:
That's all fine -- it's all going over TLS anyway (RS->AS) just
like the original token fetch by the client (C->AS). Doesn't
mean you need TLS *into* the RS (C->RS) with a good PoP token.
Can you explain how this is related to "act on behalf of"? I
don't see any connection.
-- Justin
On Dec 2, 2014, at 2:09 PM, Bill Mills <wmills_92...@yahoo.com
<mailto:wmills_92...@yahoo.com>> wrote:
Fetching the public key for a token might be fine, but what if
the introspection endpoint returns the symmetric key? Data
about the user? Where does this blur the line between this and
"act on behalf of"?
On Tuesday, December 2, 2014 11:05 AM, "Richer, Justin P."
<jric...@mitre.org <mailto:jric...@mitre.org>> wrote:
The call to introspection has a TLS requirement, but the call
to the RS wouldn't necessarily have that requirement. The
signature and the token identifier are two different things.
The identifier doesn't do an attacker any good on its own
without the verifiable signature that's associated with it and
the request. What I'm saying is that you introspect the
identifier and get back something that lets you, the RS, check
the signature.
-- Justin
On Dec 2, 2014, at 1:40 PM, Bill Mills <wmills_92...@yahoo.com
<mailto:wmills_92...@yahoo.com>> wrote:
"However, I think it's very clear how PoP tokens would work. ..."
I don't know if that's true. POP tokens (as yet to be fully
defined) would then also have a TLS or transport security
requirement unless there is token introspection client auth in
play I think. Otherwise I can as an attacker take that toklen
and get info about it that might be useful, and I don't think
that's what we want.
-bill
_______________________________________________
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
Eve Maler http://www.xmlgrrl.com/blog
+1 425 345 6756 http://www.twitter.com/xmlgrrl
_______________________________________________
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
