Hannes, What I was attempting to describe regarding OpenID is an independent organization that controls an API. I think the problem with “publisher” may be that there is confusion between publishing the software vs. publishing the API specification. Either is appropriate.
OpenID seemed like a good use case as an SDO working with OAuth. However, I don’t want to imply that OIDF needs to start issuing assertions. I did want to underline how this is beneficial to AS deployments of the Connect specs. The main idea being that administrators can configure policy that says we can now accept any registration signed by OIDF that claims to be a client for Connect. This means that AS end-points now have prior state to recognize any OIDF Connect client that knocks at the door. In this sense, it replaces the client_id manual registration model of the past….. See if this line of thought makes better sense of an explanation. I can work up some text for the draft if people agree. One important aspect is that the use of software statements reverse the issuing pattern of client_id but initially serve a similar function in recognizing clients. In 6749, Section 2.2 describes the client identifier: The authorization server issues the registered client a client identifier - a unique string representing the registration information provided by the client. The client identifier is not a secret; it is exposed to the resource owner, and MUST NOT be used alone for client authentication. The client identifier is unique to the authorization server. The software_statement replaces the client_id during the initial interaction (the registration flow) so that it may be exchanged for an individualized client_id assigned by the AS. By being signed, it enables a federated model where policy decisions can be made about the third-party statement. E.g. Is the software, the organization, the signer approved for use at this AS? Remember also, during the registration flow, we are not authenticating clients we are “registering” them. There’s no infinite proof of existence claimed here. 8-) Developers can also self-sign, but the functional characteristic is much more like what people do with (and the term escapes me), self-generated ssl tokens where public keys are exchanged on a pair-wise basis to do mutual-TLS. On a security considerations front, statements hold the same characteristics/risks of the original “public" client_id, except they are issued externally to the AS. Because they are more than a simple identifier, they have some advantage from a policy management perspective because they do not always require a prior registration record within the AS. It is the act of “registering” the software and generating a client_id that creates the confidential client in this case. Is something along these lines a better way to explain this? I can take a shot and try to address the concerns. I’m worried, I’m going in circles on this. Maybe there is a better approach? Phil @independentid www.independentid.com [email protected] On Jun 12, 2014, at 12:50 AM, Hannes Tschofenig <[email protected]> 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
