Re: [abfab] Comments on draft-ietf-abfab-aaa-saml-11

Hi Scott,

thanks for the quick review. See my comments inline.

El 07/08/15 a las 16:58, Cantor, Scott escribió:
> Just a brief review primarily of section 4 and the metadata material.
>
> 4.3.2
>
> I wouldn't denote "entityID" as <entityId> as that suggests an XML element by that name, which doesn't exist in SAML.

Right, I will remove it.

>
> Apologies if it's covered elsewhere, but these bullets seems to lack specificity:
>
>
>
>     o  RADIUS client identity in trusted digitally signed SAML request.
>
>
>     o  RADIUS realm in trusted digitally signed SAML response or
>        assertion.
>
>
> How precisely is the RADIUS identity expressed in the SAML messages?

Although it would be possible doing so, we agreed that this document 
would only provide a technical solution for representing the AAA name in 
trusted SAML metadata. If someone wanted to express them in SAML 
messages, he would need to define how this would be done.

I will state something like that at the beginning of section 4.3.3 to 
make it clear.

>
> 4.3.3
>
> One thing missing is a definition of what to put in the protocolSupportEnumeration attribute for these roles. Presumably that would be some identifier representing whatever family of profiles this binding is intended to be used with. In SAML it's used to delineate SAML 1 and SAML 2 support. It's a required attribute on every RoleDescriptor, so something has to be in it.

That confuses me. This attribute is already defined in the description 
of the RoleDescriptor type, and I thought that I did not need to provide 
further information. For instance, in the saml-metadata-2.0-os document, 
other subtypes of RoleDescriptor such as SSODescriptor or 
AttributeAuthorityDescriptor, or even subsubtypes such as 
IDPSSODescriptor, say nothing about the value of 
protocolSupportEnumeration. I just followed the same kind of description 
they do. In fact, in that document, the only place besides 
RoleDescriptor where protocolSupportEnumeration appears is in section 
"2.6 Examples", so I did include it in my examples.

Where do you suggest to include this kind of description? In the 
introductory text for each role? Why other subtypes of RoleDescriptor do 
not provide it?

>
> 4.3.4
>
> One point is that in the XML examples shown, the various string-valued elements are shown with whitespace around the values. It would be unusual to normatively address the trimming question, but I don't know if you want the examples to actually encourage extra whitespace given that no matter what you say or do, some implementations inevitably won't trim. In fact, it's probably worth noting it if you need implementations to *not* trim, but I assume these elements by and large don't expect leading/trailing WS to be significant.

You are right, I don't want the extra whitespaces to be included in the 
value of the element. What do you suggest?:
a) making the example look like this

              <RADIUSRealm>idp.com</RADIUSRealm>

or
b) using another type that has implicit trimming capabilities (if such 
thing exists)
For instance, I've seen that the localizedNameType extends xs:string, 
but it seems to have no problems with trimming.
This text is extracted from saml-metadata-2.0-os section 2.6:

<OrganizationDisplayName xml:lang="en">
     Identity Providers R US, a Division of Lerxst Corp.
</OrganizationDisplayName>

where OrganizationDisplayName is of type localizedNameType, and it is 
shown with whitespace around the values.
Does this subtype define anything special that implies trimming?

>
> 4.5
>
> This text reads a bit oddly given that the previous section explicitly covers the metadata extensions defined. At minimum, it seems like maybe it should indicate that if metadata *is* used, those roles MUST be present?

You're completely right. I will update the text.

Thanks!

-- Alejandro

>
> -- Scott
>
> _______________________________________________
> abfab mailing list
> abfab@ietf.org
> https://www.ietf.org/mailman/listinfo/abfab