Hey Aaron / Emelia I stumbled across https://www.ietf.org/id/draft-parecki-oauth-client-id-metadata-document-00.html
(was any info posted to the list?) I like the general concept. Questions: 1. If an AS supports both registered, and unregistered clients, is there any guidance or requirements on differentiating between them such as NOT issuing other identifiers that start with 'https"? 2. From a security perspective, I worry about the redirect URIs being any arbitrary URL -- perhaps that they need to start with the client_id? Is localhost supported as a redirect URI. What is the use case for an array of redirect URIs? Why not just have each of those be a different client_id? Perhaps you could just have a redirect_path that is appended to the client_id URL? 3. A number of the parameters in dynamic client registration are a negotiation between the client and the AS. For example from 7591 token_endpoint_auth_method, grant_types, response_types.scope. while including token_endpoint_auth_method = private_key_jwt is useful, the client is not getting a direct response back from the AS. How are you envisioning a mismatch between what is in these values and the response from the AS? In dynamic client registration the AS is returning what it will support. The only mechanism I can think of currently if the request is not supported is to return an invalid client error to the authorization request. 4. Along those lines, why are you pointing at 7591 rather than the list in IANA? https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#client-metadata A useful property there to call out would be initiate_login_uri. 5. Along those lines, it may be useful to recommend which of those properties are useful and why. For example, should I have a contact property? I think there should be a minimum to implement so there is interoperability -- otherwise it is hit or miss if it will work. The one bit of client_id_metadata_document_supported will unlikely not be enough to have a successful flow unless there is a MTI. 6. Did you consider signing the metadata as a JWT as being one of the content types that could be returned? That's all for now! Thanks for writing this up! /Dick
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
