[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 vladimir at connect2id.com
Thu Mar 12 09:17:33 UTC 2020


The example cases Nat gave do indeed imply continuous offline access,
where a mutable claim gets updated (by the OP itself or by the user),
and re-consent is not required.

The question here then becomes how to take care of the state.

Solution 1 as Tony proposed - the state is a function of the RP - so
when it makes the request it says "I already have these claims: ...".
But what to convey here - the received claims (their names, their names
+ values, or their names + hash of values) or just the names of the ones
that are being requested? And how to represent that. HTTP POST to the
UserInfo endpoint?

Solution 2 - the UserInfo endpoint keeps a record of which immutable
claims were released to the RP. Then when a UserInfo request is received
release those that are not as well as the mutable ones.

Both solutions have the advantage that the access token / refresh token
is not down-scoped. So the OAuth part remains unchanged.

Any other ideas?

Vladimir


On 12/03/2020 10:32, Achim Schlosser wrote:
> Commented in the ticket - I also don't yet get what should be achieved (assume its focused on offline_access scenarios)
>
> Achim 
>
> On 11.03.20, 20:50, "Openid-specs-ekyc-ida on behalf of Vladimir Dzhuvinov via Openid-specs-ekyc-ida" <openid-specs-ekyc-ida-bounces at lists.openid.net on behalf of openid-specs-ekyc-ida at lists.openid.net> wrote:
>
>     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
>     
>     
>     
>
-- 
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/20200312/29c0ec65/attachment.p7s>


More information about the Openid-specs-ekyc-ida mailing list