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


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
>



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