Registration 3.2 - Adding access url to response

[Edmund Jay]

This is an editor's note from Nat's version of the Registration spec at http://nat.sakimura.org/wp-content/uploads/2013/02/draft-openid-connect-registration-1_0.html

Add the following to the response :

_links REQUIRED. A JSON object with a member self, which in turn holds a member href, a Self URL. [[Editor's note: This is a bit pedantic, but is probably a correct way of doing it in link-rel style. Other options may be to specify in this spec that the Self URL is Registration Endpoint URL + ?client_Id=1234. ]]

[Michael Jones]

I don't believe this adds any necessary functionality. Also, the implication that every registered client should be given its own endponit with a unique URL reeks of implementation complexity. That wasn't exactly a big hit in WS-* and I don't think we should try to bring that proliferation of endpoints to OpenID Connect.

[Nat Sakimura]

As I said in the mail list, I disagree.

It does not mean that every registered client should be given its own endpoint. However, it allows the flexibility to do so as well. And this pattern + GET/POST is a big hit. It is called REST and has taken over 90% of the market.

Moreover, this pattern actually provides the backward compatibility with the d14. This is because of the flexibility. Note, in this case, flexibility does not mean multiple ways of doing it. It is defining exactly one way of doing it -- uniform interface. So, it is good for interchangeability as well.

It is also very simple to implement.

For servers, it may be as simple as inserting a fixed _links fragment to the response if it wants a fixed endpoint. It is a one liner. If it wants to have separate "logical" endpoint, or "resource" as Tony puts it, it also can do so.

For client, when parsing the response, it should just read off the value of response._links.self.href and store it. You are storing access_token. It is just one more field. Not a big issue.

[Former user]

As on the list, I agree with Nat. I think it's simple and elegant. the specific syntax of the _link.self.href structure feels a little hokey, but that's because we're trying to re-use the HAL design instead of making up something from whole cloth bespoke for this purpose.

[Michael Jones]

_link.self.href is silly JSON. It doesn't even feel like JSON.

Returning a "registration_update_url" value to go with the "registration_access_token" would be parallel. I could probably live with that.

Please just don't call this parameter _link.self.href! That's silliness.

[Michael Jones]

Actually, even better yet, if we're going to have this, call it "registration_access_url", which is even more parallel with "registration_access_token". (Although I'm not advocating having it.)

[Michael Jones]

As we discussed on the call, we already have a syntax convention for denoting that a value is an "href" - we include "_url" or "_uri" in the name. We should do that in this case as well, rather than taking a dependence on the (pedantic) HAL syntax.

[Michael Jones]

We decided to add the registration_access_url.

[Michael Jones]

Fixed #755 - Removed client update operation. Fixed #751 - Added client read operation. Fixed #749 - Added "registration_access_url". Fixed #756 - State that an updated "client_secret" value can be returned by a read operation.

→ <<cset 62fea9ed07e0>>