sounds fine to me as well. +1
On Aug 9, 2009, at 6:11 PM, Drummond Reed wrote:
> So it sounds like where this is ending up, to crib Scott's closing
> comments
> below, is, "...we should define a very minimal set of things around
> trust
> for now, and then leave the rest to profiles."
>
> If I understand Scott correctly, he's saying the XRD 1.0 spec should
> not
> itself define a specific trust model, but define the elements likely
> to be
> needed by various trust models (XRD:Subject, XRD:Link:Subject,
> signatures,
> etc.), and then leave the specifics to trust profiles.
>
> After all the discussion we've had, that approach sounds right to me,
> because I'd prefer XRD 1.0 to be as simple and stable as possible,
> and then
> let trust profiles evolve as needed, rather than to try to bind them
> into
> XRD 1.0 (or even 1.x).
>
> I'm also expecting that the TC would define a conventional
> certificate-based
> trust profile, and that the XRI Resolution 3.0 team could define its
> own
> trust profile (which I'm suspecting may be a superset of cert-based
> trust
> profile, but I'm not sure yet).
>
> In any case, I'm comfortable with this approach.
>
> Now for the bad news: due to circumstances beyond my control, I'm
> tied up
> during the day for two more weeks, and will not be able to attend the
> telecons either this week (8/13) or next week (8/20). It's not that
> I don't
> want to (though it is August ;-), but I just don't have any other
> choice.
>
> However I can continue to participate via email at night. So I'll
> try to
> keep moving things along there.
>
> To that end, I'd ask everyone reading this thread to respond +1
> (yes), 0
> (not sure), or -1 (No) to the following question:
>
> Do we have consensus that XRD 1.0 should define the XML elements
> likely to be necessary for a variety of trust models, plus any
> processing
> rules for those elements that should be universal to all trust
> models, but
> that it should stop there and say that the requirements of any
> specific
> trust model SHOULD be specified by a profile?
>
> =Drummond
>
>
>> -----Original Message-----
>> From: Scott Cantor [mailto:]
>> Sent: Sunday, August 09, 2009 2:38 PM
>> To: 'John Bradley'; 'Eran Hammer-Lahav'
>> Cc: 'Will Norris'; 'XRI TC'
>> Subject: RE: [xri] subject sets (also sort of: Agenda for August 6,
>> 2009
>> call)
>>
>> John Bradley wrote on 2009-08-09:
>>> XRD needs to specify how XRD's are signed from a XML perspective.
>>>
>>> However the XRD spec should not be mandating the relationships
>>> between
>>> the the signatures and the subject.
>>
>> Right. I also understood that there were some specific linking
>> elements
>> designed to express constraints on the result of the link, and that's
>> fine,
>> as long as they're also suitable abstracted from specific
>> approaches. This
>> was all discussed in the thread(s) on the trust models to support,
>> wherein
>> I
>> suggested that the core spec leave it at "requiring correspondence"
>> between
>> particular elements and that a specific method or two for matching
>> (e.g.
>> comparing public keys) be defined as a useful (and maybe MTI)
>> profile.
>>
>>> I think Scott and I are just saying that the core XRD spec should
>>> not
>>> preclude other trust models.
>>>
>>> I think Scott was suggesting keeping the core spec generic and
>>> producing profiles for the different use cases. Somewhat like
>>> SAML.
>>
>> Yes. Needless to say, I think that's the proper way to layer a spec
>> like
>> this.
>>
>>> The fine points of requiring RSA vs ECDSA, SHA1 vs SHA256 Keyinfo vs
>>> KeyData , as well as what needs to be verified and how need to be
>>> in
>>> a doc with a conformance requirement.
>>
>> Right. Usually conformance deals with profiles, and then includes
>> rules
>> about MTI algorithms and such, but the division of labor there is
>> relatively
>> arbitrary.
>>
>> I think that's all just another way of saying that we should define
>> a very
>> minimal set of things around trust for now, and then leave the rest
>> to
>> profiles.
>>
>> I'm also willing to help write some of this text, but was waiting
>> on this
>> subject matching stuff to stablize before I tried to help Will with
>> the
>> rest.
>>
>> -- Scott
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
