[OGSA-AUTHZ] VO SAML Attribute Profile

Chad La Joie chad.lajoie at switch.ch
Thu Jan 17 06:57:28 CST 2008


So, some of these comments are re-iterations of Tom's which I echo just 
to indicate my agreement.

- Very minor title comment.  I'd recommend something like "SAML 2.0 
Attribute Profile for Virtual Organizations"

- The document defines a number of URNs in the urn:SAML namespace.  IANA 
does not have such a namespace registered, if the intention had been to 
put it into the OASIS SAML namespace, note that you can't do that 
either.  Also, I would suggest you put in some sort of version indicator 
into those URNs so that if, for example, the vo attribute definition is 
changed between one version of a document and the next you can indicate 
this and the receiver of the attributes can do the appropriate thing.

- In section 4.1, if you really want that kind of syntax you *may* want 
to define a special schema type for that encoding, something along the 
lines of (regexp could be made more precise):

<xsd:simpleType name="groupQualifiedString">
    <xsd:restriction type="xsd:string">
       <xsd:pattern value=".+@(/.+)*" />
    <xsd:restriction>
</xsd:simpleType>

I say this knowing that most systems don't schema validate messages and 
that not all schema validators support pattern restrictions.  However I 
believe this provides a good, codified, description of what you might 
say in words as well.

- Definitely agree that the encoding method described in section 4.2 
should be dumped for the reasons given in other responses.

- In those attributes defined in section 5, I didn't see anything that 
indicated whether these attributes were meant to be single or 
multi-valued.  VO attribute is single and group and role are multi, I 
would guess.

- Is the VO attribute necessary?  If the assumption is that the VO is 
asserting this information then its identifier is already going to be in 
the assertion issuer.  I don't know that it hurts to have it twice, and 
one reason to do so may be to deal with other SAML implementations that 
don't provide access to all the information in the assertion.  Also, as 
Tom noted these VOs will need to be URIs now to server at the attribute 
authority's entity ID.

- In section 5.2 you declare a group attribute. In section 5.3 you 
declare roles, within the scope of a group.  However, you don't have any 
wording about how you would expect a client to react if a group, given 
in the scope qualifier of the role, is not included in the list of 
groups the user is a member of?  i.e. role says I'm "admin" in group 
"foo", but the group attribute doesn't say I'm in group "foo".

So, theres my initial comments.

Valerio Venturi wrote:
> Hi,
> following (with an embarassing delay) Tom Scavo's mail on defining a
> SAML profile for VOMS attribute, I'm posting a document Krzysztof
> Benedyczak and I was editing with initial thoughts on the matter.
> I'm not uploading it to gridforge until it's more complete than it is
> now.
> If the issue raise interest and we manage to agree on a document, we may
> ask Blair and DavidG about a possible recommendification, though I think
> that not being in the current charter make it difficult. Let's see, the
> discussion is anyway usefull.
> 
> I profit to wish everybody a nice holiday.
> 
> Valerio
> 
> 
> ------------------------------------------------------------------------
> 
> --
>   ogsa-authz-wg mailing list
>   ogsa-authz-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/ogsa-authz-wg

-- 
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Security
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
chad.lajoie at switch.ch, http://www.switch.ch



More information about the ogsa-authz-wg mailing list