Hi Justin, Hi Mike, thanks for updating the document so quickly.
I have re-read the new version and I have a few minor comments. You write: "The following client metadata fields are defined by this specification. All client metadata fields are OPTIONAL." I guess you mean "Optional to implement and optional to use.". Maybe it would be good to state that. In the terminology section you briefly introduce a number of actors and concepts. The description for the initial access token and the software statement is somewhat short. I am particularly interested to learn who issues the initial access token and the software statement? What is the purpose? What does it authorize? I still don't fully get the idea of having both tokens (the initial access token and the software assertion). Stating who issues those might clarify it. If different parties provide different statements or grant different authorization rights based on these two "tokens" then I am happy but with the current write-up I feel that there is something missing. Redirect URIs: The text says: "It is RECOMMENDED that clients using these flows register this parameter, and an authorization server SHOULD require registration of valid redirect URIs for all clients that use these grant types to protect against token and credential theft attacks." The security consideration section is equally weak: "For clients that use redirect-based grant types such as authorization_code and implicit, authorization servers SHOULD require clients to register their redirect_uris in full." Shouldn't the recommendation be a bit stronger particularly in light of the recently discussed covered redirect attack? What happens if the client does not provide any redirect uris? I recommend to avoid the SHOULD because it is nothing a protocol specification can fulfill. It seems to be rather a policy issue. I think there should also be a description about "full" means here as well. For example, would the AS be expected to understand something like https://*.example.com? MUST, MAY, SHOULDs: I think that the document still uses RFC 2119 language too excessively at places where it does not provide any guidance for protocol implementers. I would recommend to carefully re-read each MUST/MAY/SHOULD and judge whether it imposes any implementation specific requirements and if it doesn't to replace it with deployment recommendations instead. Also, if there is a SHOULD then it should be clear to the reader under what circumstances what action should be taken. policy_uri: In my previous review I argued that the right terminology here is privacy notice and you can even re-use the IAPP terminology. Unless the policy URI has nothing to do with privacy I would prefer this terminology change. If you disagree I would prefer to have a description about what policy means in this context. jwks: my problem with the fuzzy description is that it is not indicated how the client (or any other party) would reference the listed keys and what these would be used for. Maybe this document is not the right place to define these JWKs if the semantic cannot be defined properly. Regarding the ‘software_id' definition. You write that the software_id is asserted by the client software but wouldn't it be more reasonable that some human (in an organization) asserts something rather than software. The software just acts on behalf of the human. Would it be reasonable to say that a client developer makes these assertions. Regarding Section 4.2 client registration error response: Does a response message always contain two members, namely error and error_description? I would argue that the error member must be there but the error_description is optional. Regarding the error values I am missing a value that allows the authorization server that a specific field has to be provided and is currently absent. Ciao Hannes
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
