Re: [xri] trust vs signatures

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

Ben Laurie wrote:
> On Tue, Jan 6, 2009 at 6:44 PM, Dirk Balfanz <balfanz@google.com> wrote:
>   
>> I like the idea.
>>
>> Currently, SimpleSign uses a certuri attribute to point to the cert that can
>> be used to verify the signature. I guess that some profiles would use
>> certificates, while others would not? So perhaps the certuri attribute would
>> have to be replaced by something profile-specific?
>>     
>
> I presume you mean that the profile should specify the attributes of
> the XRD element that are profile-specific? In which case, I agree.
>
> Also, how does one figure out the profile? Should there be a standard
> mechanism for that, or is the assumption that it will always be from
> on high (e.g. "you are doing OpenID, therefore you will use the OpenID
> profile and you will build that into your OpenID app")?
>   
Should we allow the users of XRD to do whatever they please, or should 
we make is such that the producer of XRD mandate how it should be used?

If it is the former, it is "from on high" approach, and if it is later, 
it should offer a standard mechanism for it.

I think it should be later.

>   
>> Dirk.
>>
>> On Tue, Jan 6, 2009 at 9:00 AM, Brian Eaton <beaton@google.com> wrote:
>>     
>>> Hi folks -
>>>
>>> There are two proposals out there on trust and signatures.  I'd like
>>> to outline the similarities and differences and figure out which parts
>>> of each to adopt.
>>>
>>> One option is Trust Profiles [1].  The Trust Profiles proposal doesn't
>>> discuss how to sign or verify documents.  It doesn't even discuss who
>>> should sign documents.  Instead it describes a framework for talking
>>> about who should sign documents.  The idea is that different XRD
>>> applications are going to have their own specific needs around trust.
>>> Ideally each application would specify a trust profile that all
>>> implementations of that application would use for establishing trust.
>>>
>>> For example, an application dealing exclusively with HTTP authorities
>>> might use an HTTP authority trust profile, while applications dealing
>>> with other authorities and trust schemes (DNS?  DCE?  XRI?  Individual
>>> users?) would define their own trust profiles.  This approach will
>>> hopefully let us achieve both interoperability and flexibility.
>>>
>>> The other option is Simple Sign [2].  Simple Sign covers the entire
>>> trust process in one go, discussing both the bits and bytes of signing
>>> and who should sign which documents.  Simple Sign has the advantage of
>>> being simple and concise, but I'm concerned that it lacks the
>>> flexibility to deal with different trust schemes: it assumes that all
>>> applications will use a single approach for deciding who should sign
>>> documents.
>>>
>>> I like the Simple Sign approach to signing.  I'm less enthusiastic
>>> about the way Simple Sign talks about who should sign which documents.
>>>  Section 3.2 of the Simple Sign proposal offers one single rule for
>>> signing, but I'm pretty sure that one rule won't work for lots of
>>> applications.  What are those applications going to do for trust?
>>>
>>> I'd like to handle this by adopting the signing algorithm from Simple
>>> Sign (sections 1, 2, and 3.1 from the wiki), but replacing section 3.2
>>> of Simple Sign with something more like the Trust Profiles proposal.
>>> Hopefully lots of applications will be able to reuse the signing
>>> scheme, but replace decisions about trust with their own rules as
>>> appropriate.
>>>
>>> Cheers,
>>> Brian
>>>
>>> [1] Trust Profiles: http://wiki.oasis-open.org/xri/XrdOne/TrustProfiles
>>> [2] Simple Sign: http://wiki.oasis-open.org/xri/XrdOne/SimpleSign
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>>
>>>       
>>     
>
> ---------------------------------------------------------------------
> 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
>
>