From OSIS Open Source Identity Systems
This section deals with community understanding of what action an RP should take, in the case where they are passed a claim with the characteristics listed below.
* I2-Barcelona * I2 Relying Party Profiles * I2 RP Profile Claim Processing *I2 RP Profile Token Validation
Interoperability - Active
| Description
| Acceptable
| Not Acceptable
| Examples
|
| Unexpected Multi-Valued Claim: RP receives a token with a claim that contains multiple values, when the RP was expecting a single value
| fail with actionable message
| ignoring without user notification or failure
| Unexpected Multi-valued Claim Test
|
| Expected Multi-Valued Claim: RP receives a token with a claim that contains multiple values, when the RP was expecting a multiple values
| accept
| failure
| Expected Multi-valued Claim Test
|
| Unasked-for Claim Returned: RP receives a claim which was not requested by the RP
| ignore or retry ignoring case
| failure
| none yet
|
| Claim contains HTML Entities: RP receives a claim which contains embedded html (eg. <script>)
| escape HTML Entities at time of token processing
| execution of html code
| HTML Entity Test
|
| Claim contains Database Injection: RP receives a claim which contains embedded database injection code
| escape quotation marks which could otherwise cause an attacker to alter database statements.
| execution of malicious code
| none yet
|
|
|
|
|
Interoperability - Deferred
| Description
| Acceptable
| Not Acceptable
| Examples
|
| Empty Required Claim: IdP returns an empty value for a required claim
| accept or fail with actionable message
| exception with no actionable message
| none yet
|
| Claim contains Database Injection: RP receives a claim which contains embedded database injection code
| escape quotation marks which could otherwise cause an attacker to alter database statements.
| execution of malicious code
| none yet
|
|
|
|
|
Component Support
Legend: Yes = supported; No = not supported; ? = unknown; tbd = support possible near term; some = some features supported
Original Notes
Seems to be two issues here... what is in the token, and what the RP should do with it.
- The handling of claims with multivalued attributes appears not to be fully specified (Bob)
- Some RPs required an exact match of required claims and presented claims; other RPs matched if required claims were a subset of presented claims. (Bob)
- (NI) The subset seems right to me. The user has chosen to provide extra information, so I think the RP should assume she understands the privacy consequences. Furthermore, this should help keep the number of cards a user has to manage smaller. (Eric)
- Some IDPs generated tokens with claims not requested by the RP; the consensus was that IDPs should not generate claims which do not appear in the RP's list of required or optional claims, because of privacy concerns. (Bob)
- NI) But what if the user asked to have extra claims included? Does a user have this control or doesn't she? See Law 1. (Eric)
- Introduction behavior is not well-specified; when an RP encounters a token from a previously unseen IDP which is not in an administered trust list, no standard behavior is defined. Most RP failure modes provide little information to an administrator who might want to add the IDP to a trust list. (Bob)
- Some RPs rejected assertions because of issues with synchronizing clocks between IDPs and RPs. (Bob)
- "Empty Claims" from Managed Identity Providers ‑‑ how do we get around the static nature of the 'supported claims' in a managed card? (Pam)
- need an enhanced claim type, this has already come up in the WS‑Federation TC in OASIS (Tony)
- Relying Party "Faults" ‑‑ do I need to support these? ‑‑ see section 6.1 in the Identity Selector Interoperability Profile v1.0 (Pam)
