Re: [xri] Service/ProviderID

[Nat Sakimura <n-sakimura@nri.co.jp>]

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