[Openid-specs-heart] Flip the question of “Vanilla" OAuth vs. UMA

[Debbie Bucci]

>>> Unfortunately, there's no "is_alice" flag in the protocol stack that we
can count on.

Maybe there should be.   How does a client know its an OIDC client .... the
presence of the id_token?   An OAUTH client needs direct the resource owner
(assumed Alice?)  to get a token on its behalf by somehow knowing what the
authorization endpoint is  ... typically done via the RO user agent and the
redirect URI is/are given.  In the delegated flow ... Alice is not around
... could that be a trigger?   Bob (delegate) will need to have a pre
arranged relationship with the authorization server in some way or
manner.


>>>An UMA client needs to be able to be pointed to an AS, take in a ticket
(as a JSON value, regardless of what encoding the API it's speaking to
uses), talk to the "requesting party" endpoint to trade the ticket for a
token, and then it needs to be able to gather the claims that the AS gives
it hints for. As Eve keeps pointing out, those claims could be absolutely
anything, fulfilled by the client or by someone else or just because it's
Tuesday, so the client is really going to need to be written to a very
specific profile of UMA for it to have any chance of doing something
useful. Then it needs to come back with the ticket, again, and try to get a
token, potentially repeating the claims gathering cycle if it guessed wrong
on the last step.

I believe you just [primarily] explained the *on the wire* on the ATT flow
(thank you!).
Following the flow ... it seems the burden is on the Requesting party to
understand what claims the AS hints for - not the client.

I may be naive but does a client really know how many redirects occurs
until its has an access token?





>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150712/484ad82e/attachment.html>