Building on what Joseph said, it's worth separating the two ways that domains are now being used within OpenID Connect.
The first is to give people something to type, select from, or click on to start the OpenID process. This "identifier" does not need to actually be an OpenID user identifier. Rather it needs to let the client discover a token endpoint URL. Examples include davidrecordon.com, [email protected], "Twitter", etc. The second is the actual user identifier. This is what needs to be hosted over SSL if it's a URL and is ultimately what clients use to distinguish between users. Examples include https://david.example-server.com/, acct:[email protected] <acct%[email protected]>, and https://example-server.com/3192hp3hi1blknew. I am proposing that a domain needs to host a LRDD processor in order for any URLs or acct URIs to be used in either of these cases. This is to drastically simplify what a client needs to implement down to a single HTTP request. This may be the wrong decision, but I think we need to write down examples of how we expect OpenID to be used when it comes to the discovery process before making a really informed architecture decision. So I could still add a static file at http://davidrecordon.com/.well-known/LRDD which tells any client that my OpenID Connect server is https://example-server.com/token. --David On Sun, May 16, 2010 at 2:26 PM, Joseph Holsten <[email protected]>wrote: > Shade wrote: > > I'm not seeing how this "your Identity is primarily tied to your OP" > approach does anything but reinforce walled gardens. > > Compare message passing diagrams and you'll realize it's just a semantic > difference. Every RP implementor I've heard of has misunderstood the current > delegated and directed identity semantics at first. That's why Mr Norris > wrote > http://willnorris.com/2009/07/openid-directed-identity-identifier-select > > I'm sure you, like me, will have no trouble installing your own identity > provider at your vanity url of choice. > > > It's nice "when people follow the rules": grand, but useless to protect > against malicious OP's. > > Are you describing a security vulnerability? What rules must be violated > for malicious OPs to cause damage? > > > Postscript: reliance on SSL endpoints - considering how panicky the > modern browsers get over self-signed certificates, isn't this discouraging > (and effectively disqualifying) users from running their own OAuth/OpenID > endpoints? > > Yes, and it damn well should. Self signed certificates provide no form of > authentication, just encryption. OpenID doesn't need the encryption, it > needs the authentication. If you're feeling fancy, please help develop a > distributed PKI for XRI. I'm sure the TC would love any implementation > suggestions you can offer. You might also start campaigning to get clients > to start verifying DNSSec. > > But until we have some other form of authn PKI to bootstrap from, you will > eat X509 certs with a verifiable chain of authority to a known trust root > and you will like it. Just like the rest of us. > -- > http://josephholsten.com > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs >
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
