Agenda for today's call
Paul Trevithick
Agenda
- Pam’s Claim Schema Best Practices email
- Pam/Axel Claim URI as URL thread
- Review [1] from a formatting POV
- New Claims
[1] https://informationcard.net/wiki/index.php/Claim_Catalog
Paul Trevithick
Attendees
- Pam Dingle
- John Bradley
- Ian Hummel
- Drummond Reed
- Paul Trevithick
Agenda
- Pam’s Claim Schema Best Practices email
- Pam/Axel Claim URI as URL thread
- Review [1] from a formatting POV
- New Claims
[1] https://informationcard.net/wiki/index.php/Claim_Catalog
1. Claim URI Value Best Practice
Pam motivated that claims should have human-readable claim values. She argued that this scales better since software (e.g. Selectors) would only have to deal with a limited number of claim value types and further, that there are scenarios where claim type URIs are being used for which metadata discovery is not possible (e.g. when parties are using unpublished claim types). Accessibility was the prime requirement, internationalization is a secondary issue. During the discussion we used examples of human-readable claim values such as:
- “true”
- “false”
- “unknown”
- “unspecified”
We ran out of time on the 30min call, but agreed to continue this conversation on the list.
We didn’t get to any of the other agenda items.
-Paul
Mike Jones
My view is that using human-readable strings for enumeration values is unnecessary and goes against the precedent that was already set by the “gender” self-issued claim and the “age-18-or-over” ICF claim. The reason that numeric values were chosen for gender was so that the claim values would be language-neutral. It also meant that they have a compact standard representation in an “int” or “byte”.
As Axel said, the place for human-readable versions of these claim values is in the display token. Finally if people are worried programmers will make mistakes in interpreting the numeric values, I would suggest that programs can (and should) use symbolic declarations like the one below when handling these claim values:
typedef enum { RELATION_FALSE = 0, RELATION_TRUE = 1, RELATION_UNKNOWN = 2} ICF_relation_claim_t;
Both for the above reasons, and for consistency sake, I am of the view that any new claims that we define in this same space (for instance, “age-21-or-over”) should use the same numeric representations.
-- Mike
Drummond Reed
I thinking about this since the call today, I agree with Mike that “the place for human-readable versions of these claim values is in the display token”. The original ISIP specs separated display tokens from claim tokens for this very reason – to deal with the difference between human readability and machine readability of claim URIs and claim values.
This is vital from a trust standpoint too – if a user can’t trust a STS to help them interpret the claim URIs and claim values, then an STS can fool a user into doing all kinds of things. This came up this morning on the OASIS IMI TC call RE the issue of whether an RP can submit claim values to be signed by the STS (on behalf of the user). Herbert Leitold summarized the use case for this in a PDF attached to his email at:
http://lists.oasis-open.org/archives/imi/200811/msg00009.html
In this use case, what the RP wants the user to do is sign a consent that must be displayed to the user. So both the fact that it is a consent (claim URI) and the consent itself (claim value) MUST be displayed to the user in a way that the user can trust.
So it seems the dimension we’re currently missing from the claims catalog (besides machine-readable type definitions which we already know we need) is guidance and/or normative specifications for display values to be associated with both the claim URI and its values.
=Drummond
