Just requesting minimum set of claims for each Userinfo EP requests (Data minimization)
Issue #1185
on hold
Suppose a client obtained a grant to get a set of claims, e.g., Name, DoB, Address, email.
Suppose further that all of these claims were required to set up an account at the client but for day to day processes, it only needs email to send the content link to which the user has subscribed to at the client. The email address that the user uses can change at any time so the client wants to pull the email address each time before it is sending the content link to make sure that it gets delivered. (Name, DoB, Address etc. are only used for the account set up and reset.)
In this case, the client may only want to pull email using the access token that it got at the time the grant was given. AFAIK, there is no standardized syntax to do so against Userinfo EP. It would be useful if the client can set a request parameter stating “I only want email address.”
Similar use-case can be thought about in the life-insurance area. To make sure that life-insurance is properly paid out, many insurance companies only want to know if the person is alive or not. A binary claim response “is_alive”:true || false is sufficient. Once “is_alive”:false comes back, then it can pull other claims to process the pay-out.
Another use-case is for Self-issued provider. Self-issued OpenID Provider (SIOP) is providing aggregated claims, meaning that it acts as an OAuth client to the claims provider (CP). When the user who is using the SIOP wants to access an age-restricted content (e.g. is_over_18), the SIOP may only want to pull the claim from the CP, while when the user is accessing area-restricted content, it may just want to pull the postal_code from the CP. But in this kind of scenario, you do not want to make another authorization request to CP. So, the SIOP may want to obtain a full grant at the outset and later may want to pull only the claims that it needs to provide at the time it is talking to the relying party.
I guess we can re-use the same request structure but to the Resource Endpoint instead of the PAR endpoint.
Comments (11)
-
-
Based on the discussion in the call today, I understand the following use cases:
- Obtaining a subset of the consented user claims fron Userinfo endpoint
- In case of SIOP, this subset shall be signed in order to prevent the SIOP (as middle men) to modify the data in transit.
With respect to (1): I think a subset of the claims parameter (everything underneath “userinfo” could be the right way to go.
With respect to (2) I feel the assertion shall be audience restricted to the ultimate RP. This is inline with the recommendation of the core spec: “If signed, the UserInfo Response SHOULD contain the Claims iss (issuer) and aud (audience) as members. The iss value SHOULD be the OP's Issuer Identifier URL. The aud value SHOULD be or include the RP's Client ID value.“
Perhaps we make it a MUST in eKYC-IDA.
-
- changed milestone to Implementer's Draft 3
-
- changed milestone to next stage (candidates)
-
I would support Torstens view on this and suggest to split both items up in terms of following up on them next stage.
- Still seems like a topic that should be addressed within the core spec? If it is good practice to introduce such extensions that are of general interest also in the non core spec one could argue to move forward on this here. But I don’t see the urgency for this specification.
- In case of SIOP and in the context of eKYC more generally (OP is aggregating verified claims from other claim sources) - Aggregated claims are anyways passed via nested JWTs (
"_claim_sources"). It seems sensible to make signing of those MUST in case of eKYC as it is obvious that this will need to happen.
-
I shall ask OIDC core to take ownership of this. M
-
- changed status to on hold
awaiting AB/Connect response
-
-
assigned issue to
Mark Haine
-
assigned issue to
-
reporter
This should be taken up in the next AB/C WG call.
-
Any update since the discussion below?
http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20200629/007843.html
-
I think the claims aggregation draft is intended to cover this requirement.
- Log in to comment
- Assignee
- Type
- Priority
- Status
- on hold
- Component
- –
- Milestone
- next stage (candidates)
- Votes
- 0
- Watchers
- 7
For my understanding, this use-case only seems plausible in case the RP is using offline_access / refresh_tokens and wants to change the scope of claims while using these? In all other scenarios this use-case is well covered already by the core spec. mechanics.