[OGSA-AUTHZ] VO SAML Attribute Profile

[Valerio Venturi]

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