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

[Nat Sakimura <n-sakimura@nri.co.jp>]

Will,

Since I do not seem to have commit privilege, I am attaching my edit here.

Following is the change that I made.

Promoted 4.3 XRD Signature to 4. XRD Signature.
Moved 4.1 Subject Matching to 3.4 Subject Matching.
Changed 4. XRD Trust to 5. XRD Trust, and removed a section. In 5. XRD Trust, removed text and added a text to say that this should be application specific.

It is just as Eran indicated, but I did not remove the Trust section in its entirety, as I thought it would be useful to keep it as a stab so that application protocol designers can see that they should profile XRD 1.0.

=nat

Eran Hammer-Lahav wrote:

90C41DD21FB7C64BB94121FBBC2E72343783605EB8@P3PW5EX1MB01.EX1.SECURESERVER.NET" type="cite">

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
    

---------------------------------------------------------------------
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