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