Is empty claims element allowed?
There may be a use case that IDP only provides verification element, for example to provide some anonymity.
Comments (14)
-
-
reporter There was a discussion at OIDF-Japan that RP may want just the fact that IDP has verified the identity of a person without any claims.
RP (or legal authority) can ask for the identity of the person (identified by
sub
value) later if needed, but RP doesn't want it unless it becomes necessary. -
We (OneID) have explored the use case for social media where we would do verification but without sending any personal data, e.g. prove you are a human, and the same human each time (same sub), but without sharing name, address etc.
Proving you are verified/a human with an ephemeral sub could also be a valid use case.
-
-
assigned issue to
-
assigned issue to
-
I shall review wording too
-
5.2 The
claims
element MAY contain one or more of the following Claims as defined in Section 5.1 of the OpenID Connect specificationThis doesn’t seem to prohibit an empty claims element, although perhaps ‘MAY contain any of the following’ would be clearer, and adding ‘and can contain none of them.’ would explicitly allow for empty claims.
If there are no claims present, then Evidence should also not contain values (data minimisation), which seems ok as all actual values in Evidence are OPTIONAL.
-
Wording of section 5.2 does not preclude the claims element being an empty object but it is a bit ambiguous
-
Broadly agree that a little clarification of the language around this would be a good thing - Next step PR
-
PR #136 has been created.
Just a double check - section 6.5.4 talks about empty claims, but this seems to cover an error scenario where an empty claim is not expected (rather than a non-error where an empty claim IS expected). Is 6.5.4 consistent with allowing an empty claim (where this is the desired behaviour)?
If the
claims
sub-element is empty, the OP MUST abort the transaction with aninvalid_request
error.Claims unknown to the OP or not available as Verified Claims MUST be ignored and omitted from the response. If the resulting
claims
sub-element is empty, the OP MUST omit theverified_claims
element. -
reporter -
reporter empty
claims
parameter is not allowed from the initial commit -
“6.5.1. Unavailable Data
If the RP does not have data about a certain Claim, does not understand/support the respective Claim, or the End-User does not consent to the release of the data, the respective Claim MUST be omitted from the response.”
this should read ‘If the OP’.
Suggested edits for 6.5.4:
“6.5.4. Error Handling
Requested Claims that are unknown to the OP or not available as Verified Claims MUST be ignored and omitted from the response. If the resulting
claims
sub-element is empty, the OP MUST abort the transaction with aninvalid_request
error.The OP MAY return an empty
claims
sub-element, e.g., if the use case is expected to confirm a person is verified under atrust_framework
but does not require anyclaims
data.”Observations - the original 6.5.4 had 2 empty claims conditions which seem to clash; if claims is empty, omit verified_claims (but also abort transaction)
Is ‘invalid_request’ the right error for an unexpected empty claims sub-element? The request is valid, but the response isn’t?
-
- changed status to resolved
Resolved by PR#136
-
Remove minProperties from claims_type to allow empty claims
See Issue 1317 and PR 136 for related discussions.
→ <<cset f1976dce1786>>
- Log in to comment
“
claims
: REQUIRED. Object that is the container for the Verified Claims about the End-User.“For me the verification element is about the claims and without any claims object
verification
is meaningless. Perhaps the way to support the use case might be to useppid
, an ephemeral idetifier or not having an identifier at all and just presenting any claims that are needed (there are surely some claims needed).Could you give more detail on the use case?