>>> Marius wrote: >>> >>> I was suggesting that portability can be resolved between the user >>> and >>> the IdP. I cannot see how the protocol can help this by passing two >>> identifiers. And if only the portable identifier is passed then >>> there is >>> no need to mention the IdP-specific identifier. >> >> Marius, see the analysis at >> http://www.lifewiki.net/openid/ConsolidatedDelegationProposal, now >> updated >> to include Josh's lastest thinking from >> http://openid.net/pipermail/specs/2006-October/000357.html. >> >> In sum, not being able to send the IdP-specific identifier: a) >> forces the >> IdP to redo resolution, which is unnecessary and slows performance, >> and > >Not necessarily. When you register with the IdP most likely you will >claim all your portable identifiers with this IdP, so the IdP knows >about them.
With XRI i-name/i-number infrastructure that's neither practical nor desirable. With XRIs, users control their own synonyms, i.e., I can register a delegated i-name within a specific community (for example, at @example.community I could register @example.community*drummond) and then point that at my personal i-name (=drummond.reed) and the IdP for =drummond.reed will never know -- and doesn't need to know. I could go to any RP and login in as @example.community*drummond, the RP will resolve this to =drummond.reed (through the way XRI resolution automatically handles reference processing -- let me know if you want more info about this), and end out storing the CanonicalID i-number for =drummond.reed (which is =!F83.62B1.44F.2813). >> b) prevents the protocol from being stateless. > >How? The RP deals only with the portable identifier and this is the >only thing the IdP sends back. Why do you need state? It follows from the above. But this is so important that I'm going to send a separate message about it. =Drummond _______________________________________________ specs mailing list email@example.com http://openid.net/mailman/listinfo/specs