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] trusted discovery workflow


Hi Brian,

thanks for putting this up. A few comments:

- 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

- the terms you're defining, and the algorithm you're giving, are so abstract that it's hard to find any fault with it. So I'm going to speculate on some of the incarnations of this stuff and see whether what you're saying still makes sense.

(1) How do we get the Authoritative Key for a reference before dereferencing it? If R is some document then I can imagine that it can list the identifier of the authoritative key for the next reference in the discovery chain. But what if R is, say, the email address "bob@foo.com". We imagine that this email address points (in some yet-to-be-defined way) to the next reference in the discovery chain (which eventually leads to the metadata about this email address). But it cannot tell us what its authoritative key is. Wouldn't it be more natural to assume that authenticated references (of which "bob@foo.com" is not an example) are signed, and that we check whether the key used to sign them is authoritative? So you would have a procedure that, when we find an authenticated reference, goes _back_ and makes sure that the key used to sign the authenticated reference is in fact authoritative; as opposed to assuming that we can find (or at least name) an authoritative key _before_ we dereference a reference.

(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.

Putting these two things together, how about something like this:

fuction(Reference R) returns Reference:

int MAX_ITERATIONS = the maximum number of hops you wish to follow before giving up
Reference lastAuthenticatedReference = R
for (iteration = 0; iteration < MAX_ITERATIONS; ++iteration)
if R is Null
// Discovery has failed
return Null

if R is authenticated
Key K = key_used_to_sign(R)
if K is NOT authoritative for lastAuthenticatedReference
// trust verification failed
return Null

// are we done?
if R has metadata of type T
return R

// authentication succeeded, but we haven't found our metadata yet.
// authentication means delegation  
lastAuthenticatedReference = R

R = followReference(R, T)
I don't know - at this point things are so abstract that it's hard to tell which one is better - but I have a feeling that it might be easier to do "if K is NOT authoritative for lastAuthenticatedReference" than it is to do "currentAuthority = nextR.delegatedAuthority"

Dirk.

On Thu, Dec 4, 2008 at 8:37 AM, Brian Eaton <beaton@google.com> wrote:
I've put a proposal for a discovery work flow that results in a
trusted document on the wiki.  Comments and criticism most welcome:

http://wiki.oasis-open.org/xri/XrdOne/TrustWorkflow

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php




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