I would be OK with the change to registration_access_url or something
similar to that. The main argument against it is that we'd be inventing
a bespoke field for something that's already covered out there by the
HTTP Linked Data world. Nat did a good job of trying to generalize
concepts of linked OAuth metadata with
http://tools.ietf.org/html/draft-sakimura-oauth-meta-01
I don't think it's inherently silly to try and generalize the problem,
but I can appreciate the argument that such generalization could be
overkill in this instance.
-- Justin
On 02/11/2013 08:12 PM, Mike Jones wrote:
It seems like significant overkill, bordering on silliness, to use the syntax
_links: {
"self": {
"href":
"https://server.example.com/register/s6BhdRkqt3";
}
}
to represent a value that could be more straightforwardly represented as:
"registration_access_url": "https://server.example.com/register/s6BhdRkqt3";
Even some of the advocates for it have called it "pedantic". I believe that
most developers would have less charitable things to say about it, and would wonder why
we're trying to foist needless complexity on them.
I'll also point out that this syntax is based upon an expired individual
submission draft http://tools.ietf.org/html/draft-kelly-json-hal-03 that is not
in any working group. I don't believe we should take a dependence on this
draft or this syntax.
Occam's razor says that this isn't needed.
-- Mike
-----Original Message-----
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Justin Richer
Sent: Monday, February 11, 2013 1:15 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Registration: HAL _links structure and client self-URL
Draft -05 of OAuth Dynamic Client Registration [1] returns a URL pointer for
the client to perform update and secret rotation actions. This functionality
arose from discussions on the list about moving towards a more RESTful pattern,
and Nat Sakimura proposed this approach in the OpenID Connect Working Group.
This URL may be distinct from the Client Registration Endpoint URL, but draft
-05 makes no promises as to its content, form, or structure, though it does
contain implementor's notes on possible methods.
Two questions arise from this change:
- The semantics of returning the client manipulation URL
- The syntax (derived from HAL for JSON [2], an individual I-D
submission)
On semantics:
Pro:
- The server has flexibility on how to define the "update" endpoint, sending
all clients to one URL, sending different clients to different URLs, or sending clients
to a URL with a baked-in query parameter
- The client can take the URL as-is and use it for all management operations
(ie, it doesn't have to generate or compose the URL based on component parts)
Con:
- The client must remember one more piece of information from the server at
runtime if it wants to do manipulation and management of itself at the server
(in addition to client_id, client_secret, registration_access_token, and others)
Alternatives include specifying a URL pattern for the server to use and all
clients to follow, specifying a query parameter for the update action, and
specifying a separate endpoint entirely and using the presence of items such as
client_id and the registration access token to differentiate the requests. Note
that *all* of these alternatives can be accommodated using the semantics
described above, with the same actions on the client's part.
On syntax:
Pro:
- Follows the designs of RFC5988 for link relations
- The HAL format is general, and allows for all kinds of other information
to be placed inside the _links structure
- Allows for full use of the JSON object to specify advanced operations on
the returned endpoint if desired
Con:
- The rest of OAuth doesn't follow link relation guidelines (though it's
been brought up)
- The HAL format is general, and allows for all kinds of other information
to be placed inside the _links structure
- The HAL-JSON document is an expired individual I-D, and it's unclear what
wider adoption looks like right now
Alternatives include returning the URL as a separate data member
(registration_update_url), using HTTP headers, or using JSON Schema.
-- Justin
[1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
[2] http://tools.ietf.org/html/draft-kelly-json-hal-03
_______________________________________________
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
