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

Thu Mar 12 09:29:07 UTC 2020

How about something a bit like the HTTP If-Modified-Since header but with the intent being to return only things that have changed since the given date?

I think we should also be slightly wary of treating DoB or National Id number as immutable data - I believe there have been occasions where discovery of a birth certificate has revealed someone’s been using an incorrect DoB their entire life, and I’m sure typoes, human error and bad OCR are going to be a problem at some point - i.e. even verified ekyc data can’t be guaranteed to be 100% error free.

The only wrinkle would be that we would probably need a way to tell the RP “a claim I had previously asserted was true I no longer do” for the case where (say) fraud or an error is discovered and the OP needs to say “since date XXXX, I’ve changed my mind and I can no longer assert the users DoB”.

This would introduce quite a bit of complexity on both sides though, to some extent it seems simpler to just return all the data and let the RP figure out how to deal with what has changed or has been removed.

Joseph

> On 12 Mar 2020, at 09:17, Vladimir Dzhuvinov via Openid-specs-ekyc-ida <openid-specs-ekyc-ida at lists.openid.net> wrote:
> 
> 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 <mailto:openid-specs-ekyc-ida-bounces at lists.openid.net> on behalf of openid-specs-ekyc-ida at lists.openid.net <mailto: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
> 
> 
> -- 
> Openid-specs-ekyc-ida mailing list
> Openid-specs-ekyc-ida at lists.openid.net <mailto:Openid-specs-ekyc-ida at lists.openid.net>
> http://lists.openid.net/mailman/listinfo/openid-specs-ekyc-ida <http://lists.openid.net/mailman/listinfo/openid-specs-ekyc-ida>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ekyc-ida/attachments/20200312/b78e2f85/attachment-0001.html>