You're right that UMA bundles several things in the protection API (covered by
the protection scope, whose keyword is actually the resolvable URI
"http://docs.kantarainitiative.org/uma/scopes/prot.json";). One of those things
is the use of the token status endpoint; the rest is the whole mechani
Hi Justin-- Glad to see this moving forward. This draft seems pretty
straightforward, and I imagine the UMA core spec could probably incorporate a
reference out to this rather than continuing to use our custom-specified method
for what we'd called "token status". I wanted to highlight a couple o
Preparing generically for context to be provided by the RS/host, as well as
metadata provided back by the AS/AM, seems like a good idea, and hopefully
doesn't have to be over-complex. Extension points can be quite simple if
designed right. But I agree that the basic use case of "give me back the
>But even so, I think the simple case of "I have a token and want to
>know
>about it" needs to be supported without extra scaffolding.
+1
>
> -- Justin
>
>
>
>On 11/30/2012 02:06 PM, Eve Maler wrote:
>> You're right that UMA bundles several things in the protection API
>> (covered by the p
I think this approach makes sense and it gels with the basic concept
that I'd had about the response from the introspection endpoint being
extensible and, at some level, service specific. An interesting question
then is do we want to have some kind of signaling from the client as to
what they w
Hi Eve,
Yes, you've got the right idea. In a lot of cases that we're dealing
with, the relationship between the RS and AS is set up ahead of time. So
the RS knows which AS to ask, and the AS knows how to deal with the
different RS's it cares about. UMA gives you a nice dynamic way to
introduc
