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