From ISIP 1.5:
<ic:InformationCardMetaData>
[Information Card]
<ic:IsSelfIssued> xs:boolean </ic:IsSelfIssued>
<ic:PinDigest> xs:base64Binary </ic:PinDigest> ?
<ic:HashSalt> xs:base64Binary </ic:HashSalt>
<ic:TimeLastUpdated> xs:dateTime </ic:TimeLastUpdated>
<ic:IssuerId> xs:base64Binary </ic:IssuerId>
<ic:IssuerName> xs:string </ic:IssuerName>
<ic:BackgroundColor> xs:int </ic:BackgroundColor>
</ic:InformationCardMetaData>
[Information Card]
<ic:IsSelfIssued> xs:boolean </ic:IsSelfIssued>
<ic:PinDigest> xs:base64Binary </ic:PinDigest> ?
<ic:HashSalt> xs:base64Binary </ic:HashSalt>
<ic:TimeLastUpdated> xs:dateTime </ic:TimeLastUpdated>
<ic:IssuerId> xs:base64Binary </ic:IssuerId>
<ic:IssuerName> xs:string </ic:IssuerName>
<ic:BackgroundColor> xs:int </ic:BackgroundColor>
</ic:InformationCardMetaData>
.../ic:InformationCardMetaData/ic:IsSelfIssued This required element indicates if the card is self-issued (“true”) or not (“false”).
.../ic:InformationCardMetaData/ic:IssuerId This required element contains an identifier for the Identity Provider with which a self-issued credential descriptor in a card issued by that Identity Provider can be resolved to the correct self-issued card. The element content may be empty.
The ic:IssuerId value used for a card when representing it in the Information Cards Transfer Format SHOULD be computed as a function of the ds:KeyInfo field of the envelope digitally signed by the Identity Provider. Specifically:
Use the IP Identifier as the ic:IssuerId value. The ic:IssuerId value SHOULD be the empty string for self-issued cards.
- Compute IP Identifier in the same manner as RP Identifier in Section 8.6.1, except that the certificate from ds:KeyInfo is used, rather than the Relying Party‟s.
Use the IP Identifier as the ic:IssuerId value. The ic:IssuerId value SHOULD be the empty string for self-issued cards.
.../ic:InformationCardMetaData/ic:IssuerName This required element contains a friendly name of the card issuer.
The ic:IssuerName value used for a card when representing it in the Information Cards Transfer Format SHOULD be computed as a function of the ds:KeyInfo field of the envelope digitally signed by the Identity Provider. Specifically, if the certificate from ds:KeyInfo is an extended validation (EV) certificate [EV Cert], then set ic:IssuerName to the Organization Name (O) field value from the certificate, otherwise set ic:IssuerName to the Common Name (CN) field value from the certificate.
ISIP 1.5 does not state what the value for IssuerName is in the case when IsSelfIssued == true. I think it SHOULD be empty too like IssuerId when IsSelfIssued == true.
[update: Just saw that the XML schema defines IssuerName to be of the type "StringMaxLength64MinLength1". It can not be empty. I suggest that we do away with this "required element should be empty if..."-stuff and define IssuerId and IssuerName to be optional. Or better: We should move IssuerId into the definition "SelfIssuedCredentialType" as it is needed only for this authentication type.
For IssuerName I suggest that we move this element into the Information Card type "InformationCardType" and define it to be not-there for self-issued cards and non-empty for managed cards. The issuer should have the right to choose its name. Deriving it from the cert imposes unneeded restrictions on the issuer. The card is signed and after I verified/validated and accepted the card from that issuer I should accept its choosing for IssuerName.]
IssuerId and IssuerName are defined in the section of ISIP 1.5 titled: "7. Information Cards Transfer Format" and subsection "7.1. Pre-Encryption Transfer Format"; that is: They are needed/computed when a card is exported? This does not make sense. I assume that they are computed when the .crd file is imported.
The XML in the .crd file is signed and the ds:KeyInfo from the signature contains the certificate that is used to sign the XML.
What if the ds:KeyInfo from the signature contains no ds:X509Certificate?
Question: Is there a connection between ic:IssuerId and ic:IssuerName from the ic:InformationCardMetaData and ic:Issuer from ic:InformationCard?
Answer: No. The ic:Issuer from ic:Information card is an URI and is the logical name of the issuer. Potential RPs and Issuers must agree on this logical name because it is used to determine a matching card when the RPs asks for a specific issuer in the HTML object tag.
If the RP limits the accepted tokens to those issued by issuer="urn:flabergasted" then there is no intuitive way to find an STS that issues these tokens. Should the issuer from the HTML object tag be the same as the ic:IssuerName? Probably.
So, what is the use of IssuerId and IssuerName? IssuerName is used to present it to the user when the managed card is displayed to the user. IssuerId is used to find the self-issued card when the managed card is backed by a self-issued card. If the UserCredential is has no ic:SelfIssuedCredential child then IssuerId is not needed.
-----
What if the issuer uses another certificate to sign the issued managed Information Card than for its SSL connection? Is this a "legal" scenario?
No comments:
Post a Comment