[higgins-dev] Question about mapping attributes to claims

[Michael McIntosh <mikemci@xxxxxxxxxx>]

I wanted to bring to the mailing list a debate/discussion we've recently 
started over on the #higgins IRC channel in order to get a broader opinion 
on how to deal with this situation "correctly". Some questions that we've 
been discussing include:

What should the STS do when an RST is received which requires a claim in 
the returned token, but the IDigitalSubject.getAttribute(uriClaim) returns 
null?
a) Return a token with an empty claim?
b) Return a token without the claim?
c) Generate a SOAP Fault?

According to the Draft CardSpace Guide: "A relying party can ask for one 
or more claims in the token issued by an identity provider. If any 
required claims are missing in the token submitted, it can accept or 
reject that token at its own discretion."

The specific claim type that caused this debate was "group membership". 
The group membership attribute is multi-valued and can therefore result in 
a claim that looks like:
<saml:Attribute
  AttributeName="groupmembership"
 
AttributeNamespace="http://schemas.xmlsoap.org/ws/2005/05/identity/claims";>
  <saml:AttributeValue>user</saml:AttributeValue>
  <saml:AttributeValue>admin</saml:AttributeValue>
</saml:Attribute>

When IDigitalSubject.getAttribute(uriClaim) returns null the current 
Higgins STS implementation does "a" resulting in a claim that looks like:
<saml:Attribute
  AttributeName="groupmembership"
 
AttributeNamespace="http://schemas.xmlsoap.org/ws/2005/05/identity/claims";>
</saml:Attribute>

In order to accomplish this the current implementation creates the 
Attribute element, then calls IAttribute.getValues and iterates thru the 
returned IPropertyValue objects, adding an AttributeValue element for 
each.

There are essentially two code paths that could result in an empty claim, 
a) IDigitalSubject.getAttribute(uriClaim) returns null, and b) the 
iterator returned from IAttribute.getValues provides no values. 

Conceptually there is a subtle difference between a claim that is present, 
but contains no values, and one that is absent. In the group membership 
example, a claim that is present but has no values makes the explicit 
statement that the subject is not a member of any group, whereas a missing 
group membership claim says nothing about whether the subject belongs to 
any group. 

Presumably the distinction should be made between a missing attribute and 
one with no values. One way to differential between the two cases would be 
for IDigitalSubject.getAttribute(uriClaim) returns null to result in no 
claim, and IAttribute.getValues provides no values to result in an empty 
claim.

The problem is that in the case of the LDAP, when the last value for a 
multi-valued attribute is removed, the attribute itself is removed. 
Therefore, when using the LDAP CP, it is not currently possible to 
differentiate between when a claim should be present but empty, or not 
present (IDigitalSubject.getAttribute(uriClaim) ALWAYS returns null - when 
there are no values or when the attribute is not present).

I am trying to think of ways we can work around this. One way would be for 
some sort of metadata to be associated with attributes to help context 
providers do the right thing.

Would anyone else like to join the discussion?

Thanks,
Mike