Re: [xri] trust vs signatures

[Brian Eaton <beaton@google.com>]

OK, cool.  I liked Drummond's suggestion of trying to validate the
trust profile idea by writing up a new profile and seeing if it makes
sense.  Drummond suggested your OpenID CX work as a good candidate for
a new trust profile; do you agree?  If so, do you have the time to try
writing up the profile?  I'd also love to see a DNS trust profile for
Peter's work.

I don't want to be the one to write up those trust profiles because I
don't know the use cases or the trust relationships well enough to
write something reasonable.  Trust is very application specific.

On Tue, Jan 6, 2009 at 9:48 PM, Nat Sakimura <n-sakimura@nri.co.jp> wrote:
> As to the "cert" is concerned, though it is currently written to be X.509, I
> think it could equally be something like GPG.
> If we separate out the trust portion, that becomes easier and the SimpleSign
> becomes more generic.
> (i.e., I like the idea.) Of course then, we need to tell what kind of cert
> it is as well. Perhaps we should indicate it in the XRD/@sigalg.
>
> =nat
>
> 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
>> <mailto: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
>>
>>
>