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

["Drummond Reed" <drummond.reed@cordance.net>]

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