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 model profiles decision (was RE: subject sets (also sort of: Agenda for August 6, 2009 call))


+1

On Mon, Aug 10, 2009 at 11:06 AM, Will Norris<will@willnorris.com> wrote:
> 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:cantor.2@osu.edu]
>>> 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
>>
>
>
> ---------------------------------------------------------------------
> 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
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]