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


Before I start tackling this, let me be sure of what it is trying to 
achieve.
Since it is XRD/XRI discussion list, I will think in terms of XRD.

The authenticity of individual XRD can be estabilished by just 
inspecting it through SimpleSign.
(See SimpleSign proposal how it is so.)

The XRD document points to another resource with its own XRD for a service.
This may be pointing to yet another resource with its own XRD, etc., so 
it creates a chain.
What this TrustWrokflow is trying to achieve is to evaluate the 
authenticity of this chain.
(This actually is what XRI Trusted Resolution 2.0 tried to solve.)

Is this correct?

If so, I have another question. (This applies to XRI Trusted Resolution 
2.0 as well.)

In my view,

   R0 deligating to R1
   R1 deligating to R2

does not necesarily mean that R0 agreed to deligate to R2.
i.e., the transitivity is not granted unless it is explicitly done so.

How is such cases being handled?

#I feel that there should be a flag that indicate further deligation is 
allowed in the original XRD/Service element.

=nat


Brian Eaton wrote:
> On Thu, Dec 4, 2008 at 12:06 PM, Drummond Reed
> <drummond.reed@cordance.net> wrote:
>   
>> From a first read-through, it looks like XRI 2.0 trusted resolution using
>> SAML signatures as defined in section 10.2 of [1] conforms to your
>> algorithm. (I'm not at all suggesting we use that for XRD since it was
>> complex enough that there was only one early implementation.) I'm just
>> testing my understanding of the algorithm you are proposing for "signed
>> links".
>>     
>
> They definitely have some similarities.  In particular the sentence...
>
> "If the digital signature enveloped by the SAML assertion contains a
> ds:KeyInfo element, the resolver MAY reject the signature if this key
> does not match the signer's expected key as specified by the
> ds:KeyInfo element present in the XRD Descriptor that was used to
> describe the current authority."
>
> ... makes me think that there is a similar concept of delegation happening.
>
> I'm not 100% sure of that, though.
>
> ---------------------------------------------------------------------
> 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
>
>   

-- 
Nat Sakimura (=nat)
Nomura Research Institute, Ltd. 
XDI.ORG Vice Chair



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