Hi Phil, thanks for your response. A few remarks below.
>> I am particularly interested to learn who issues the initial >> access token and the software statement? What is the purpose? What >> does it authorize? > > These tokens have very different characteristics. The Software > Statement is not a security token. It is a statement that locks the > registration profile for client software and provides AS endpoints > with a way to recognize client software since they do not have a > client_id yet. In practical terms, AS endpoints can set policy to > automatically approve reject based on specific statement, or content > rules (software_id, version etc) or even approve based on the signer > of the statements (e.g. allow registration for any client software > statement signed by Cisco). The software statement is hopefully signed and you are going to make some security relevant decisions based on it. Whether you call it a security token or not does not really matter that much. > > Typically, the statement would be generated once (for all copies > distributed) by the developer, publisher, or a collective > organization. I think it would be useful to add information about who creates it, particularly since the document introduces these parties (at least the client developer, and the software API publisher). You might also expand a bit on what you mean by "generated once" to give guidance on when a new software assertion needs to be generated vs. when a previous one can be re-used. > This is particularly useful when the publisher of an > API is not the same organization as the deployers of the actual API > endpoints following a common open API specification. For example, > OpenID Connect would be one such example. OpenID Connect would not have come to my mind here since OpenID connect is neither a client developer nor a software API publisher (at least in my understanding of the terminology defined in the dynamic client registration document). > > In the early OAuth1 and 2 days, most use cases had the API publisher > and the deployer as the same organization. A client_id could be > issued in advance and could be used as both credential id and > software identifier. In the evolving world, we have lots of cases > (e.g. OpenID Connect) where the organization that defines the API > specification is not the same as the one operating implementations of > the API specification. Client_id can’t serve both purposes. > Software statement fills the gap allowing client software to use a > client statement “claim” that can be “exchange” for a deployment > assigned client_id. I think that this would be useful background motivation for the draft; I disagree with the mentioning of OpenID Connect based on my previous comment. > > Initial access token is a security token that allows the client to > register in a closed/restricted registration endpoint where anonymous > registration may not be allowed. Useful in some environments where > an IT organization might re-package a client for distribution on an > internal or private system. > > Where the software statement is issued by either the developer or the > API specification organization, the initial access token is typically > issued by the “domain” (or an organization affiliated with it) where > the client intends to register. Using the terminology from the dynamic client registration draft the initial access token is issued by the "Deployment Organization". This would be important information to add to the document! Ciao Hannes
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
