We are in complete agreement.
This means we need to move 4.3 (XRD Signature) to its own top section (following 3).
Also, we should move 4.1 (Subject Matching) into section 3 because XRD/Link/Subject is undefined for any other use case at this point.
And get rid of the rest of the trust section...
EHL
> -----Original Message-----
> From: John Bradley [mailto:]
> Sent: Saturday, August 08, 2009 11:37 PM
> To: Eran Hammer-Lahav
> Cc: Scott Cantor; 'Will Norris'; 'XRI TC'
> Subject: Re: [xri] subject sets (also sort of: Agenda for August 6,
> 2009 call)
>
> OK,
>
> 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.
>
> If they are used for XRI resolution the application may not be using
> the CN from the certificate in the signature to match against the
> Subject of the XRD.
>
> If SAML were to use XRD meta-data in conjunction with SAML meta-data I
> could see quite a different trust model event though it would be using
> LRDD + XRD.
>
> I think the trust model we are talking about is one that specifically
> relates to the LRDD + XRD use case for openID and oAuth where people
> want to use conventional CA based PKI.
>
> This will be the most common use case but is not the only one.
>
> 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.
>
> 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.
>
> Perhaps that is what you are saying as well.
>
> Scott feel free to correct if I misinterpreted what you were getting
> at.
>
> John B.
>
> On 8-Aug-09, at 10:17 PM, Eran Hammer-Lahav wrote:
>
> > LRDD is not going to touch trust. It is a generic method for
> > associating a resource with a description. One of its methods
> > include an XRD document about the host. That too will not touch
> > trust. The whole point was for something else (i.e. XRD) to define
> > the exact steps a client can perform to validate trust if it is
> > provided and it so desired.
> >
> > I don't know how to translate what you are suggesting into what the
> > spec is going to offer.
> >
> > I was under the impression that all this was done. If we are still
> > discussing trust related issues, as this seems to suggest, I would
> > like to immediately split that whole section off and move forward
> > without it, with trust being published as a separate spec.
> >
> > We are going in circles.
> >
> > EHL
> >
> >> -----Original Message-----
> >> From: John Bradley [mailto:]
> >> Sent: Saturday, August 08, 2009 2:20 PM
> >> To: Scott Cantor
> >> Cc: Eran Hammer-Lahav; 'Will Norris'; 'XRI TC'
> >> Subject: Re: [xri] subject sets (also sort of: Agenda for August 6,
> >> 2009 call)
> >>
> >> Tying the authority segment of the subject to the CN of the signing
> >> cert is a trust model that works for LRDD. It won't work for XRI
> or
> >> other things that may use XRD.
> >>
> >> We do need a complete solution for LRDD but it shouldn't preclude
> >> other trust models for XRD.
> >>
> >> John B.
> >> On 8-Aug-09, at 1:32 PM, Scott Cantor wrote:
> >>
> >>> Eran Hammer-Lahav wrote on 2009-08-08:
> >>>> That's what we set to do. If the trust section does not provide
> >>>> this as a
> >>>> complete solution, it is pointless.
> >>>
> >>> I'm not trying to prevent your complete solution, I'm just talking
> >>> about how
> >>> it should be structured as a matter of spec design.
> >>>
> >>> There can't be *one* trust model for XRD. That's never going to
> fly.
> >>> There
> >>> are obvious points of flexibility, and anywhere you start
> connecting
> >>> XRD to
> >>> something like X.509, that's got to be pretty adapatable. If you
> >>> need to
> >>> profile it down for particular use cases (e.g. requiring self-
> >>> assertion),
> >>> then that can be included, and even required for conformance
> >> purposes.
> >>>
> >>> -- 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
> >
