[Openid-specs-ab] HAL enhanced OAuth 2.0 response – Making OAuth 2.0 slightly more RESTful
torsten at lodderstedt.net
Sat Sep 1 07:54:28 UTC 2012
in my opinion, the resource should be
The authorization of this request is orthogonal. So including a token
via request header fits in very well.
Am 30.08.2012 17:22, schrieb Nat Sakimura:
> (low priority and just for the sake of discussion)
> Continuing a little more on this thread after the conversation this morning:
> 1. About token response not having a unique associated identifiers.
> The resource we are talking about here is an abstract resource which
> is being represented as the token response. The token response
> actually has a unique URL at least in the code flow. It is:
> 2. About userinfo endpoint being not bound to a resource
> If we regard the userinfo URL as
> then, it is uniquely identifying the resource.
> It would be even better if it were like:
> Note: if we are using URI template and HAL, then we actually would not
> need to define the userinfo endpoint API. href in the _link with the
> relationship of "userinfo" would return something like
> and it would have still worked equally.
> No. I am not proposing a change to userinfo endpoint.
> It is actually easier for the client to just hard code the parameters
> than parse the URI template.
> However, it does seem to be an interesting thought expedient that I
> may learn a little more about being RESTful.
> On Wed, Aug 29, 2012 at 12:54 PM, Nat Sakimura <sakimura at gmail.com> wrote:
>> I created a new blog post: HAL enhanced OAuth 2.0 response – Making
>> OAuth 2.0 slightly more RESTful
>> Food for your thought.
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
More information about the Openid-specs-ab