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
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
