+1
Trust Models are application (e.g., OpenID, OAuth, XRI Resolution,
etc.) specific.
XRD should provide facilities that they can use to create their
profile.
Though examples are useful, it should not be exclusive.
Having said that, checking against common use cases would be a useful
exercise to make sure that we are providing necessary toolkit, so
we would have to do it regardless.
For that matter, XRI resolution team, please sketch the XRI trusted
resolution
based on current draft. I suppose it is potentially a non-X.509 based
model
with a priori known root public key and signature chaining.
On the separate topic: for Cool URI for non-information resource,
in the last call, we were suggesting that we should probably use
Cool URI format for the rel type urls and three of us had a consensus
on it.
=nat
Drummond Reed wrote:
0B10C6CC430F4F9D81FE6E38366A273B@ELROND"
type="cite">
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
|