[OpenID-Specs-eKYC-IDA] [EXTERNAL] Issue #1185: Just requesting minimum set of claims for each Userinfo EP requests (Data minimization) (openid/ekyc-ida)

[Vladimir Dzhuvinov]

Could you elaborate a bit? Is the RP sending those claims as part of the
request to the OP to prove that it already has them?

Vladimir

On 11/03/2020 19:04, Anthony Nadalin via Openid-specs-ekyc-ida wrote:
> Nat, in the cases that you list this is what I would call a "presentation proof", that is the issuer is not presenting the claims but the "client" is presenting and refactoring of the original claims in a way that they can be verified by the issuer.
>
> -----Original Message-----
> From: Openid-specs-ekyc-ida <openid-specs-ekyc-ida-bounces at lists.openid.net> On Behalf Of Nat via Openid-specs-ekyc-ida
> Sent: Wednesday, March 11, 2020 9:53 AM
> To: openid-specs-ekyc-ida at lists.openid.net
> Cc: Nat <issues-reply at bitbucket.org>
> Subject: [EXTERNAL] [OpenID-Specs-eKYC-IDA] Issue #1185: Just requesting minimum set of claims for each Userinfo EP requests (Data minimization) (openid/ekyc-ida)
>
> New issue 1185: Just requesting minimum set of claims for each Userinfo EP requests (Data minimization)
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitbucket.org%2Fopenid%2Fekyc-ida%2Fissues%2F1185%2Fjust-requesting-minimum-set-of-claims-for&data=02%7C01%7Ctonynad%40microsoft.com%7C179e4f75f34b4f534bb708d7c5dcb19d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637195423978962686&sdata=JYfACEum1JNC3Z%2FJxnQGc5uSDZtJTMGfT583gyPBlq0%3D&reserved=0
>
> Nat Sakimura:
>
> 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.
>
>
-- 
Vladimir Dzhuvinov


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-specs-ekyc-ida/attachments/20200311/2ba0ab6a/attachment.p7s>