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