OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xri] Trust (was: Re: [xri] Re: The elements formerly known as TargetAuthority and TargetSubject)


Nat Sakimura wrote on 2009-07-14:
> It is a rather basic use case.
> 
> Suppose I host my own XRD on my host: sakimura.org, including my OpenID,
> sakimura.org/nat. I am not providing OpenID Authentication Service
however.
> So, I am delegating to exampleop.com. So, it would look like:

That part I get. What I don't understand is the intended meaning of the
KeyInfo within the XRD, or what else, if anything, is needed within the
<Link> block to accomplish whatever is needed to make OpenID work.

> This XRD has to be able to establish its authenticity through its
signature.
> Otherwise, linking to another XRD as above may not be authoritative
either.

Right, but that XRD signature itself is more of a classic problem. I'm not
saying there's some easy answer there, and I don't really think this spec
needs to say much about it one way or the other.

I'd also note that there's no connection between the Signature (any any
KeyInfo that might be inside it) and the KeyInfo in the XRD. If they "match"
in some sense, you have a self-signed document of course. If not, you can I
suppose say that the signer is claiming that the KeyInfo in the XRD "belongs
to" the Subject. At least I assume that's the intended semantic.

But there's this intended notion of linking XRDs and somehow tying that to
trust evaluation, and that's where I was focusing my comments.

> I agree. I have discussed that back in iiw2008b as well.
> We could have put the public key in the <Subject>.
> As long as the user secret key is not compromised, this looks good.
> The problem is the key rotation. You might want to change the
> key-pair for one reason or another. This would imply changing the
> cannonical ID (<Subject>), and has adverse effect in terms of
> OpenID etc. that you would have to transition the ID on RPs as well.

This is where I would have to understand the use case better, but in
general, if you're trying to use the XRD to represent the key(s) controlled
by the Subject, you can make it multi-valued to handle key rotation.

-- Scott




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]