I don’t think so. All copies of a client may carry the same statement. Special distributions of a client intended for use in a specific domain may be packaged with an initial access token. So a subset of every client may have the token.
All clients registering within a secure domain would have both statement and initial access token. Other clients registering in other domains may or may not have initial access tokens. A good example of this, many IT orgs take software from people like Cisco and embed special keys etc in a private distribution. When the software installs it is pre-configured with keys and config to work only within the IT orgs domain. I think this is the model Justin was looking for. If a single client instance could have a unique initial access token already issued, we probably wouldn’t need dynamic registration. 8-) Phil @independentid www.independentid.com [email protected] On Jun 12, 2014, at 12:52 AM, Hannes Tschofenig <[email protected]> wrote: > 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 >> > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
