Consolidated Delegate Proposal

[Martin Atkins]

Dick Hardt wrote:
> 
> Won't the IdP will still have to resolve the i-name? The IdP can't  
> trust the RP, or know that the i-name and i-number are really linked  
> unless it checks itself.
> 

The IdP is only authenticating the i-number. The i-name is for display 
to the user and possibly to allow the user to choose that as the display 
identity to send back to the RP. The only attacks possible are:

* RP tries to "fool" the user into authenticating as a different 
i-number by sending a false i-name. I'm not sure what the benefit of 
this attack would be for the RP.

* The RP tries to convince the IdP to send back an incorrect display 
identity back in the response. But then the RP is just fooling itself!

The spec should probably contain some words to say that the IdP should 
not do any processing on the public identifier (whether it be a 
delegated HTTP URL or an XRI) that relies on the i-name to i-number 
mapping without first ensuring that the mapping is correct; any such 
processing would be outside of what is required for the Auth spec, though.

Assuming for the moment that we've conceptually "separated the public 
identifier from the IdP token" per my proposal, the public (delegate) 
identifier or i-name is for the RP (it checks the mapping), and the IdP 
token (which is some URI that doesn't necessarily even have to be 
resolvable) is for the IdP. Both parties validate their own token; if 
either party doesn't validate its own token, it opens itself up to the 
other party telling lies. However, they do not have to authenticate 
*each-other*'s tokens.

The RP's validation of its own token is defined by the spec. The IdP's 
authentication is not defined by the spec; the IdP doesn't necessarily 
even have to resolve its own tokens, but it can do if it wishes.

>> Lastly, in the case where the identifier-the-RP-stores and the
>> identifier-the-IdP-stores are different, if the RP has already  
>> discovered
>> the latter, then the RP can be stateless by sending both to the  
>> IdP, knowing
>> it will receive both back in the response.
> 
> Then the RP is trusting the IdP will send back a correct mapping.

This one bothers me too. Unless the RP can sign its initial request 
parameters to stop the IdP from tampering with them, I don't see how the 
RP can trust the IdP to return a correct mapping.

My old stateless RP demo implementation just re-resolved this stuff when 
it got back the response to make sure that the IdP was telling the 
truth. I'd love to hear that this was unnecessary, since it did double 
the identity resolving overhead.


> This discussion has me wondering about XRI resolution though. Given  
> that multiple i-names can resolve to the same i-number, just as  
> multiple domain names can resolve to the same IP address, and that  
> the i-name is the identifier the user sees, it would seem tht the i- 
> name is what should be stored by the RP, otherwise there is no  
> difference between using any of the i-names that resolve to the same  
> i-number, or is that the idea?

I think this is the intention, though it does show an interesting 
inconsistency between the use of XRIs and the use of i-numbers. I 
currently have three URL-based identifiers all pointing at the same 
server and the same Yadis document, yet those identifiers are distinct. 
However, in the comparable XRI case, it would appear that those 
identifiers would all be considered to be the same.

I wonder how easy it is to get hold of new i-numbers. If they are 
basically "throw-away" cheap, then I'm able to decide for myself how to 
distribute my mappings to separate them. However, if these i-numbers are 
going to be "expensive" (for some sense of the word) to aquire, I've got 
less freedom in this respect. Drummond?