Should personal cards allow arbitrary claim types?

[Paul Trevithick]

Personal cards should support an arbitrary set of claim types.

ISIP Spec

It appears that the ISIP spec agrees. The ISIP spec does say that the self-issued IdP (i.e. the selector) must support at least these 15 claim types: [1]. But it doesn’t say that any particular card can’t support an arbitrary set of claim types.

CardSpace Implementation

We decided to do a test of CardSpace in this regard. We extended p-card claim types by adding the http://schemas.xmlsoap.org/ws/2005/05/identity/claims/testClaim (the exact URI isn’t important) and created a personal card with this additional claim. The attached pCardExt.crds file contains that card. In addition the file pCardExt.xml is a decrypted version of pCardExt.crds (its password is "password").

We were unable to import this card into CardSpace (.NET 3.5 SP1); it returns "The data is invalid". So, it appears that CardSpace does not support additional claim types for personal cards. Attached as the file pCardUsual.xml is a decrypted standard p-card for reference.

Another test (that we’ve not yet done) would be to create a personal card that contains only claims that are not included in the set of 15 [1].

--Paul

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

[Axel Nennker]

One problem is that there is now way to tell the self-issued-card-STS
what possible values in the display token for that claim are.
Not that there is a display token for this STS anyway.
How should the selector display this claim? What is it name?

-axel

On 20 Jan., 19:35, Paul Trevithick <ptrevith...@gmail.com> wrote:
> Personal cards should support an arbitrary set of claim types.
>
> ISIP Spec
>
> It appears that the ISIP spec agrees. The ISIP spec does say that the
> self-issued IdP (i.e. the selector) must support at least these 15 claim
> types: [1]. But it doesn¹t say that any particular card can¹t support an
> arbitrary set of claim types.
>
> CardSpace Implementation
>
> We decided to do a test of CardSpace in this regard. We extended p-card

> claim types by adding thehttp://schemas.xmlsoap.org/ws/2005/05/identity/claims/testClaim(the exact

> URI isn¹t important) and created a personal card with this additional claim.
> The attached pCardExt.crds file contains that card. In addition the file
> pCardExt.xml is a decrypted version of pCardExt.crds (its password is
> "password").
>
> We were unable to import this card into CardSpace (.NET 3.5 SP1); it returns
> "The data is invalid". So, it appears that CardSpace does not support
> additional claim types for personal cards. Attached as the file
> pCardUsual.xml is a decrypted standard p-card for reference.
>
> Another test (that we¹ve not yet done) would be to create a personal card
> that contains only claims that are not included in the set of 15 [1].
>
> --Paul
>

> [1]https://informationcard.net/wiki/index.php/Claim_Catalog#Well_Known_C...
>
>  pCardUsual.xml
> 89KAnzeigenHerunterladen
>
>  pCardExt.crds
> 121KAnzeigenHerunterladen
>
>  pCardExt.xml
> 89KAnzeigenHerunterladen

[Paul Trevithick]

Axel,

Within a personal card there is a <SupportedClaimTypeList> element and within that there are <SupportedClaimType> elements. For example:

<SupportedClaimTypeList>
  ...
  <SupportedClaimType Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname">
     <DisplayTag>First Name</DisplayTag>
     <Description>First Name</Description>
  </SupportedClaimType>
  ...

So we can just provide these same descriptive elements for the “new” claim types too, no?

--Paul

[Axel Nennker]

Yes. I saw this too after I had sent my answer. But then I decided
that I had to read the whole spec again.
I think that should we go this way then some sections of the spec need
clarification.
Maybe one of the original authors/designers can shed some light into
this?
My guess is that e.g. the possibility to use the supportedclaims-
element (as you wrote) is a mere accident in the schema definition
identity.xsd. We need supportedclaims for the managed cards and only
that makes this element available for self-issued cards. I am only
guessing and can not see into the head of the original authors/
architects of the spec. Don't want to offend Kim, Arun, ...

And we need a best-practice guide for selector implementors too. If a
relyingparty does NOT specify an issuer, should the selector then
offer to create a "matching" self-issued card (when a matching managed
is not available)? How does the selector determine the type (string,
xsd-date, tri-boolean, boolean, doctype...) of a claim?

I am not against this. I fact I often wondered why the user should not
be able to issue other claims about himself then the small set of
predefined ones.

Did you implement this through in Azigo, Higgins selectors? Will read
the higgins-dev list now.

I guess there is some work to do if we want to support this. For the
openinfocard selector I can say that the self-issued claims are
hardcoded (in many places).
It is luck that the openinfocard selector has no import/export ;-) ?

-Axel

On 21 Jan., 00:24, Paul Trevithick <ptrevith...@gmail.com> wrote:
> Axel,
>
> Within a personal card there is a <SupportedClaimTypeList> element and
> within that there are <SupportedClaimType> elements. For example:
>
> <SupportedClaimTypeList>
>   ...
>   <SupportedClaimType
> Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname">
>      <DisplayTag>First Name</DisplayTag>
>      <Description>First Name</Description>
>   </SupportedClaimType>
>   ...
>
> So we can just provide these same descriptive elements for the ³new² claim
> types too, no?
>
> --Paul
>

[Paul Trevithick]

Hi Axel,

As you suggested, moving this thread to the icf-all list...
See ## inline.

On 1/21/09 12:32 AM, "Axel Nennker" <ignis...@googlemail.com> wrote:

Yes. I saw this too after I had sent my answer. But then I decided
that I had to read the whole spec again.
I think that should we go this way then some sections of the spec need
clarification.

## If so then the ICF OASIS Coordination WG is the place to collect the feedback and feed to the OASIS IMI TC.

Maybe one of the original authors/designers can shed some light into
this?

## I’m hoping one of them will respond here.

My guess is that e.g. the possibility to use the supportedclaims-
element (as you wrote) is a mere accident in the schema definition
identity.xsd. We need supportedclaims for the managed cards and only
that makes this element available for self-issued cards. I am only
guessing and can not see into the head of the original authors/
architects of the spec. Don't want to offend Kim, Arun, ...

## You may be right.

And we need a best-practice guide for selector implementors too. If a
relyingparty does NOT specify an issuer, should the selector then
offer to create a "matching" self-issued card (when a matching managed
is not available)?

## I don’t understand the problem here. If the RP doesn’t specify an issuer then the selector should just look for whatever cards support the set of required claims. Some might be personal cards, others might be managed cards. The user picks one as usual, etc.

How does the selector determine the type (string,
xsd-date, tri-boolean, boolean, doctype...) of a claim?

## I can think of a few options; this is an issue to work on. [Personal opinion: a fallback is that new ICF-minted claim type URIs should resolve to metadata representations that the selector could read & cache. The ICF Schemas WG is laying some foundations for this. But we likely need something simpler too!]

I am not against this. I fact I often wondered why the user should not
be able to issue other claims about himself then the small set of
predefined ones.

## Yes.

Did you implement this through in Azigo, Higgins selectors? Will read
the higgins-dev list now.

##  The current Higgins code is also hard-coded, but we’re in the process of fixing that now. We’re just getting started on this.

I guess there is some work to do if we want to support this. For the
openinfocard selector I can say that the self-issued claims are
hardcoded (in many places).

## Yeah. Higgins too.

It is luck that the openinfocard selector has no import/export ;-) ?

## !