Agenda for today's call

0 views
Skip to first unread message

Paul Trevithick

unread,
Nov 24, 2008, 2:33:12 PM11/24/08
to ICF.WG.Schemas
641-715-3200 / 1024-634

Agenda
  1. Pam’s Claim Schema Best Practices email
  2. Pam/Axel Claim URI as URL thread
  3. Review [1] from a formatting POV
  4. New Claims

[1] https://informationcard.net/wiki/index.php/Claim_Catalog

Paul Trevithick

unread,
Nov 24, 2008, 3:24:33 PM11/24/08
to ICF.WG.Schemas
641-715-3200 / 1024-634

Attendees
  1. Pam Dingle
  2. John Bradley
  3. Ian Hummel
  4. Drummond Reed
  5. Paul Trevithick

Agenda
  1. Pam’s Claim Schema Best Practices email
  2. Pam/Axel Claim URI as URL thread
  3. Review [1] from a formatting POV
  4. 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”
Ian argued that if we do define standard values, we should standardize on English (as above examples). John pointed out that for managed cards it would be the STS generating these values in the display token.

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

unread,
Nov 24, 2008, 4:33:40 PM11/24/08
to icf-wg-...@googlegroups.com

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

unread,
Nov 24, 2008, 9:56:05 PM11/24/08
to icf-wg-...@googlegroups.com

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

 


Ian Hummel

unread,
Nov 25, 2008, 8:26:13 AM11/25/08
to icf-wg-...@googlegroups.com
Drummond,

I think we need two things... for claim value spaces such as the tri-valued "boolean" we use (and will use again) for age-X-or-over claims we need to publish the XSD for the lexical representation of all claim values.  A conforming RP/STS should always send or receive these representations on the wire, and having the XSD should allow them to unambiguously parse the response in any language.  We should probably create a new page called Claim_Data_Types so that we can refer back to these definitions as the claim catalog grows.

We should also include in this table the preferred "Display Token" format for any types which are enumerated... this would be English, but someday we could add a localization table too.

e.g.(wg are types defined in this wg)


date type              (lexical) representation on the wire            display token

xs:boolean              true OR 1 / false OR 0               True False  (never TRUE, Yes, YES, 1, etc...)
wg:trivalued             0, 1 or 2                                        True False Unknown
wg:bloodType        o+, a+, b+ etc... O+, A+, B+ (always capitalized)


etc...


I am coming at this from the perspective that it is the claim's type which determines its display token format, not really the claim URI itself.
Reply all
Reply to author
Forward
0 new messages