Validating i-name claims.

There will be many ways in which people will assert claims over the internet and depending on the nature of the claim and the identity of the claimant we will have to do different types of validation. I’m talking about claim validation in a dynamic trust environment, in a distributed identity network. There is no assumption of a prior relationship between the asserting party (AP) and the Relying Party (RP).

When I talk about validating a claim what I’m really talking about is; is there a way for the RP to be sure that the AP can be trusted for this specific claim. When I say ‘this specific claim’ I mean 2 things;

1) that the AP is trusted by the community to make this claim type (just because they are trusted for one claim doesn’t mean they should be trusted for all claims)

2) that the identifier about which the claim is being made has indicated that this is their designated AP for this claim. (I think this is only an issue in some claim types)

Specifically I am starting with i-name claims and I will explore this from an InfoCard perspective. This is a totally valid way to authenticate ‘ownership’ of an i-name although the mechanism is totally different from an http redirect authentication protocol like OpenID, BBAuth, Google’s SAML implementation, etc… In the http redirect case the i-name is the identifier and therefore validation/authentication of ownership is the point of the entire interaction. In the InfoCard case the i-name is just another piece of metadata associated with the PPID. Self asserted claims about i-name ownership should never be accepted.

So here’s what an RP should do when they get an i-name claim via InfoCards…

Perform SEP resolution to find the designated ‘InfoCardService’ published by the owner of the i-name. The only AP that should be acceptable for claims about that i-name should be that entity. This should be enough validation. (Obviously you are checking the crypto to make sure that the AP is who they say they are.)

In order to defeat this validation a would-be spoofer would have to have subverted the XRI resolution and inject their own SEP; if the RP is using the http proxy resolver this can be achieved by subverting the DNS layer. Once I start to assume that DNS is compromised any validation starts to fall apart… so either use a local resolver in trusted resolution or some other mechanism of trusting your resolution infrastructure if you deem it necessary… personally I’m not sure that the value of the i-name claim in this context requires a particularly high level of paranoia. In the InfoCard usecases it’s the PPID that is the identifying key, and any additional services derived from the i-name should be separately validated anyway.