Re: [xri] trust vs signatures

[Peter Davis <peter.davis@neustar.biz>]

I also like the idea of maintaining separate trust and signing  
profiles. Should we pursue this path, then we will need define the XML  
structures in such a way to convey which is being used, and keep them  
generic enough to be usable to new profiles. The alternative being  
that we define the schema for XRD to allow attributes from another  
namespace.

I have not managed to convince myself that one approach is better than  
the other wrt schema impact.

=peterd

On Jan 6, 2009, at 1:44 PM, Dirk Balfanz 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?
>
> 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
>
>