OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xri] subject sets (also sort of: Agenda for August 6, 2009call)


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:jbradley@mac.com]
> 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:jbradley@mac.com]
> >> 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
> >



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]