Re: [xri] Service/ProviderID

[John Bradley <jbradley@mac.com>]

OK,  I hadn't considered non-resolvable CID.

With a resolvable CID and no cert you can always do the manual procedure to verify the CID.

If you resolve it over https: and all the redirects are over https: taking you back to the same document you can be relatively certain that you have the right XRD for that CID.

Or if you use XRI CID validation you get the same behavior.

What you are proposing would add a CID that could only be verified via a CERT.

Perhaps we need an example of that.  

My guess is that one might be tempted to use email addresses as CID.

Would mailto:ve7jtb@gmail.com#12345 count as a coolURI?

Someone at the W3C will have an opinion on that.

It may or may not be resolvable depending on site-meta etc,  but google could create a cert for it if they wanted to.

So the URI element is the providerID or a resolvable synonym for it.

=jbradley

 

On 11-Dec-08, at 2:29 AM, Nat Sakimura wrote:

Hi John,

comments inline.

John Bradley wrote:

Thanks for the slide.

The one part I don't quite get is why in the openID SEP don't you do

discovery on https://nri.co.jp/# !1616!0001 rather than http://uniid.nri.co.jp/server/

They must be synonyms, and require the same number of steps to resolve.

If you resolve http://uniid.nri.co.jp/server/  and it produced some

other CID would you fall back and resolve the CID or error?

Actually, if <ProviderID> (and so is <CanonicalID>) happens to be a cool
URI, yes, it can be.
On the other hand, if <ProviderID> happens to be "Subject" filed in
RFC3280 compliant (and the SHOULD in it for Subject non-reuse policy was
taken as MUST for the compliance, and in which case
SubjectUniqueIdentifier is empty) X.509 certificate, then, you cannot do
the resolution on it.
So, you need to do discovery on the URI specified in <URI> field, which
needs to be a cool uri. (The example does not look like a cool uri, and
I should fix it.)

Now I could see the URI element being diffrent if it were the actual

openID endpoint but published link headers to http://uniid.nri.co.jp/server/xrd

 rather than doing a 303.

That could have a useful backwards compatibility of sorts.  Perhaps

that is what you are thinking as the same URI is repeated in the

openID SEP in the delegated XRD.

Yes. And I tried to be nice to AWWW :-)

I would personally like to see the SEP contain only the ProviderID and

perhaps LocalID or other-elements that might override or extend the

elements in the delegated XRD.  Overriding is perhaps a debatable idea

but at-least extend.

As I have stated above, <ProviderID> and thus <CanonicalID> may not be
resolvable.
At least, I want to allow that kind of possibility. This means we need a
<URI> element, which may happen to be equal to <ProviderID> after all.

=nat