Hannes, I should also add one security consideration.
If a server believes it is receiving a registration request from a client sharing the same software_id and software_version as another client that uses an assertion, the server should find the registration suspect. It is likely the client is attempting to change things like redirect_uri’s. The point of a software statement is to lock all copies of a client to behave the same way under the same registration profile. Phil @independentid www.independentid.com [email protected] On Jun 12, 2014, at 9:51 AM, Phil Hunt <[email protected]> wrote: > 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 _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
