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 <
> <mailto:>> 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
>
>
