[OAUTH-WG] Feedback on draft-jenkins-oauth-public-00

[George Fletcher <[e-mail]>]

Providing feedback/questions regarding this individual draft:

Section 1.1
* is there a reason that only email address based login identifiers are 
supported? It seems like this profile could be used for other use cases 
as well.

Section 1.2
* I would recommend this document be more generic and then a specific 
profile for say IMAP can be defined that then also defines the scopes 
required for use with an IMAP server.
* This document can just say that scopes required are out of scope (pun 
intended)

Section 2.1
* Recommend changing the last sentence to... The rest of this document 
describes in detail each of the above steps.

Section 2.2
* I recognize that Security Considerations will be filled out in a 
future version. A topic that needs to be present is the potential 
implications of proceeding with the flow when not all the required 
metadata fields are present. I suspect most authorization servers do not 
have a 'registration_endpoint' URL in their metadata configuration :)

* Can you clarify why the 'token_endpoint_auth_methods_supported' MUST 
include "none"? If the client is dynamically registering, then it can 
receive it's own instance specific client_id and client_secret which 
allows it to authenticate to the token endpoint. Not requiring client 
authentication seems dangerous.

* Similar comment for 'revocation_endpoint_auth_methods_supported'

Section 2.3
* I do not think the developer should be able to do the registration. 
Instead, this should be required to be completed by the client. This 
will be the expectation of the Authorization Server if it supports 
Dynamic Client Registration.

* There are security implication with using a custom scheme. Best 
practice for mobile apps is to use claimed URIs rather than custom 
schemes. If custom schemes are the only option in certain cases the risk 
need to be clearly called out in the Security Considerations section.

* I'm strongly against allowing the 'token_endpoint_auth_method' to be 
"none". There is no reason that the default of 'client_secret_basic' 
can't be used (as far as I understand the profile). I recommend that the 
registration response from the Authorization Server also include a 
'client_secret'. The client can then store the secret appropriately on 
the device. This secret is instance specific and hence the device must 
be compromised to extract that secret and impersonate the user.

Section 2.5
* I believe the client should authenticate itself via some mechanism and 
not just present the client_id

Thanks,
George