Hi Chad, On Thu, 2008-01-17 at 13:57 +0100, Chad La Joie wrote:
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.
I thought those identifiers were placeholders while an agreement were reached. If an OGF bless will be given to this profile, we may use OGF URIs.
- 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.
Good suggestion.
- Definitely agree that the encoding method described in section 4.2 should be dumped for the reasons given in other responses.
Looks like there's a general agreements on that.
- 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.
You're right.
- 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.
I don't mind that. This way, a consumer would know the subject is in a VO based on the fact that the assertion was issued by an entity representing a VO. Then the consumer is supposed to have knowledge that a certain entityID represents a VO. This would leave us with just having to agree on a common format for entityIDs for VOs. The only problem I would see with that if that if the assertion consumer is supposed to compose an authz request decision, XACML for example, she would have to create an attribute and fill it with the entityID name. One may argue that's not our business to define XACML attributes for VOs, but it is to promote interoperabilities with other specs form the WG.
- 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".
Is that in the scope of an attribute profile? An implementer may well choose to use only the role attriute and not the group. Valerio