One other small remark: I assume that a single software statement is distributed to many OAuth clients whereas the initial access token is only distributed to a single OAuth client. Is that correct? Is that the envisioned relationship?
On 06/12/2014 09:50 AM, Hannes Tschofenig wrote: > 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 > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
