[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