RE: [security-services] Groups -sstc-saml-x509-authn-attrib-profile-draft-10-diff.pdf uploaded

["Ari Kermaier" <ari.kermaier@oracle.com>]

[Resent due to email outage.]

Tom,

I've taken a stab at going through your proposed edits from draft-10-diff -- my thoughts are below. Overall, this looks good, though I want to go through the metadata section and schema a little more carefully.

A question: Are there any comments/questions that you've posted to the mailing list (or that others have posted in response) that are not captured in this draft? If so, would you mind trying to cull them from the various threads into one place?

[line 20, et al.] Is there a reason that the profile should not specify X.509 v3 certificates, but leave it open to the possibility of v2 or (shudder) v1 certs? I think we need to examine the potential implications to see if this is a substantive change that broadens the scope of potential interoperability issues.

[line 122] Why not call out the use-case descriptions as non-normative?

[line 170] While it is undoubtedly more correct to construct the Basic Mode URI from the new namespace URI you've introduced for the profile, I'm not sure we can make such a normative change at this point -- there are existing implementations/deployments to consider.

[lines 185-186] The way I read SAMLCore section 8.3.3, the encoding rules for the DN actually differ from those in RFC 2253, as defined by XML Signature, so the MUST and SHOULD contradict each other here. I think we should simply reference SAMLCore for the NameID Format rules, and not repeat that material.

[lines 188-189] If the NameID content DN is encoded as per XML Signature (SAMLCore 8.3.3), but the NameQualifier value DN is encoded as per RFC 2253, we might have a confusing situation. Does anyone know what the originally proposed usage was for this profile?

[lines 232-233] Same comment as for [line 170].

[lines 360-450] I would hesitate to introduce new normative MUST requirements here that might break existing implementations' conformance with the profile spec. I think metadata usages should be RECOMMENDED, as in previous drafts, except insofar as the SAML 2.0 metadata spec already contains MUSTs.

[lines 509-515] Again, we need to rationalize the subject DN formating issue between SAMLCore 8.3.3 and RFC 2253.

::Ari

-----------------------
Ari Kermaier
Sr. Development Manager
Oracle Corporation


> -----Original Message-----
> From: tscavo@ncsa.uiuc.edu [mailto:tscavo@ncsa.uiuc.edu]
> Sent: Thursday, July 06, 2006 4:12 PM
> To: security-services@lists.oasis-open.org
> Subject: [security-services] Groups -
> sstc-saml-x509-authn-attrib-profile-draft-10-diff.pdf uploaded
> 
> 
> The document named 
> sstc-saml-x509-authn-attrib-profile-draft-10-diff.pdf
> has been submitted by Tom Scavo* to the OASIS Security 
> Services (SAML) TC
> document repository.
> 
> Document Description:
> A PDF snapshot (with diffs) of 
> sstc-saml-x509-authn-attrib-profile-draft-10
> 
> View Document Details:
> http://www.oasis-open.org/apps/org/workgroup/security/document
> .php?document_id=19053
> 
> Download Document:  
> http://www.oasis-open.org/apps/org/workgroup/security/download
> .php/19053/sstc-saml-x509-authn-attrib-profile-draft-10-diff.pdf
> 
> 
> PLEASE NOTE:  If the above links do not work for you, your 
> email application
> may be breaking the link into two pieces.  You may be able to 
> copy and paste
> the entire link address into the address field of your web browser.
> 
> -OASIS Open Administration
>