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

[John Bradley <jbradley@mac.com>]

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
>