Re: [xri] trusted discovery workflow

[Dirk Balfanz <balfanz@google.com>]

On Thu, Dec 4, 2008 at 11:33 AM, Brian Eaton <beaton@google.com> wrote:

On Thu, Dec 4, 2008 at 10:01 AM, Dirk Balfanz <balfanz@google.com> wrote:
> - it would be nice if you stated explicitly what the inputs and outputs of
> the algorithm are. I believe they are the following:
>
>   input: (Reference R, KeyIdentifier currentAuthority)
>   output: Reference (is Null if trust cannot be established)
>
> - currentReference is never used inside the loop

Thanks, fixed.

> (1) How do we get the Authoritative Key for a reference before dereferencing it?

I think that's a separate discussion from the discovery work flow.
Deciding which Keys are trusted for which references is going to be
highly dependent on individual applications of discovery.  (Possible
solutions are https style key discovery or pairwise key exchange based
on signed contracts or the canonical id proposal in the
XrdOne/SimpleSign wiki.)

Sure. But you're assuming _some_ properties about these unnamed mechanisms, namely, that the key (identifier) that is authoritative on a reference will be available before we dereference that reference.

I'm wondering whether it would make more sense to make the opposite assumption (that the key will be available _after_ the reference has been dereferenced). Seems like a strictly more general way to go (if I know the key beforehand, I'll know it afterwards, but not the other way 'round), and allows us to keep our options more open with respect to what those unnamed key-trust-mechanisms are.
 

> (2) Could we simplify the algorithm by assuming that authentication means
> delegation? I.e., if I don't want to delegate to a different authority, I
> don't sign my reference. If I _do_ want to delegate, then I sign it. And the
> place I'm forwarding to _is_ the authority to which I'm delegating.

No.  Authenticated data is useful even if it doesn't delegate.  For
example, signing metadata about an OpenID signon URL does not imply
additional delegation.

It doesn't? Let's say we're trying to find the access token endpoint for an OpenID provider that supports the OAuth OpenID extension. 
Presumably, at some point my claimed_id will say "my OpenID signon URL is over there", signed by a key authoritative for my claimed_id. We would then look up metadata of that URL, and that metadata would tell us where the OAuth access token endpoint is, and it would be signed by the OpenID OP. It would be neat if the trust flow followed the discovery chain automatically there.

I agree that generally speaking, pointing to the next element in the discovery chain is not the same as delegation, but I'm wondering whether in the case of _metadata discovery_, this is always one and the same thing, in which case we could simplify the process.

Dirk.