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@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@switch.ch, http://www.switch.ch