[Openid-specs-ab] Review Comments on Dyn Reg

[Mike Jones]

Thanks for the useful review, as always Torsten.  This is my Disposition of Comments (DoC) reply to your review.  If I accepted your suggestion, I haven't included any reply to it here.  The changes resulting from this review have been released at http://openid.bitbucket.org/.



2.  Grant Type and Response Type are not actually orthogonal – especially in the general OAuth case, so in the general case, both need to be specified – hence, the need for an identifier for the Implicit Grant.



3.2 Another way of saying this is that “The same Client Secret value MUST NOT be assigned to multiple Clients”.  That seems like a sensible security precaution.  I’ve changed the text to say that, since it’s clearer.  Otherwise, a client_secret for one Client could be tried and might work for another Client.



5.  The value of a read-only management endpoint is that an updated client_secret value can be returned.



                                                            -- Mike



-----Original Message-----
From: Torsten Lodderstedt [mailto:torsten at lodderstedt.net]
Sent: Wednesday, November 06, 2013 6:12 PM
To: Openid-specs Ab; Mike Jones
Subject: Review Comments on Dyn Reg



Hi Mike,



here are the comments on Dyn Reg.



2.



grant_types - there is no grant type "implicit". I therefore suggest to remove this bullet and all occurrences of "implicit" in the following table of response type/grant type combinations.



I would an "implicit" client expect just to register the response types token or id_token (and the respective combinations).



jwks_uri - How is this scheme supposed to work for native clients? I assume any instance of such an application would use a distinct key pair, which is stored locally. Is the client supposed to provide a web server interface? I would rather expect this kind of client to provide the public key data directly.



3.2



client_secret - "This MUST be unique for each client_id." - why must the

client secret be _unique_? This seems to be a rather hard requirement.



4.



I would call section "implementation notes" and move it to the end of

the doc (or merge it into section 9). Right now it suddenly turns up

during registration and management, which might confuse people and

induce them to think it is normative.



"When stateless dynamic client registration is used by the Authorization

Server, read operations are likely to not be possible." Why?



5.



"to be able to view and update its registered information" - I only see

a specification of the read operation. Where is the update? As the next

states "The only method defined for use at this endpoint by this

specification is the HTTP GET method" I think the update should be

removed.



What is the value of a read only management endpoint?



I would not return client_secret since this is the credential.

I would not return the registration_uri as the client already knows it.

It just sent a request to it.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131217/a6226aae/attachment.html>