RE: Trust model profiles decision (was RE: subject sets (also sortof: Agenda for August 6, 2009 call))

[Eran Hammer-Lahav <eran@hueniverse.com>]

+1

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> Sent: Sunday, August 09, 2009 6:11 PM
> To: 'XRI TC'
> Cc: 'Scott Cantor'; 'John Bradley'; Eran Hammer-Lahav; 'Will Norris'
> Subject: Trust model profiles decision (was RE: subject sets (also sort
> of: Agenda for August 6, 2009 call))
> 
> 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
>