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] trust vs signatures


I agree that conceptually it seems attractive. But I am not enough of an
expert in either trust or signing to immediately weigh in one way or
another. What seems to make a lot of sense to me is to try out this approach
by taking the following steps:

1) Post a wiki page on the strawman "generic" signing mechanism (either
modify http://wiki.oasis-open.org/xri/XrdOne/SimpleSign or create a new page
devoted just to a generic signing).

2) Post wiki pages for two or three proposed trust profiles (e.g., one for
OpenID, one for Nat's OpenID CX work, one for something quite different from
both of those). On these pages, post a strawman for the profile itself, and
then an example showing how it would profile the use the generic signing
mechanism.

If we can do that, it will not only flesh out the concept pretty well, but
it should give us a clear picture of what needs to be in a profile and what
requirements profiles present to the generic signing mechanism.

Thoughts?

=Drummond 

> -----Original Message-----
> From: Peter Davis [mailto:peter.davis@neustar.biz]
> Sent: Tuesday, January 06, 2009 11:26 AM
> To: Dirk Balfanz
> Cc: Brian Eaton; XRI TC
> Subject: Re: [xri] trust vs signatures
> 
> 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
> >
> >
> 
> 
> 
> ---------------------------------------------------------------------
> 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]