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

Torsten Lodderstedt torsten at lodderstedt.net
Thu Mar 12 09:59:54 UTC 2020


> On 12. Mar 2020, at 10:53, Ivan Kanakarakis via Openid-specs-ekyc-ida <openid-specs-ekyc-ida at lists.openid.net> wrote:
> Hello all,
> On Thu, 12 Mar 2020 at 11:29, Joseph Heenan via Openid-specs-ekyc-ida
> <openid-specs-ekyc-ida at lists.openid.net> wrote:
>> 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.
> I cannot agree more. I do not see any real reason why returning all
> the attributes again would be a "bad thing”.

One reason could be that the OP charges the RP per claim it provides. In this case, the RP might want to optimise its costs. 

best regards,

> I'm feeling more like
> what has been described is trying to work around a problem that the RP
> should be solving.
> The server is not responsible for the client's state.
> If someone actually needs this, one can extend the protocol and define
> a new endpoint for this reason. I do not think this special behaviour
> should be done on an existing well-defined endpoint.
> In addition, I do not think this is in the scope of this
> specification. It may be _related_ but I do not see it as a core/vital
> part of this work.
> Cheers,
> ---
> Ivan Kanakarakis
> -- 
> Openid-specs-ekyc-ida mailing list
> Openid-specs-ekyc-ida at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ekyc-ida

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3946 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ekyc-ida/attachments/20200312/6fb8a077/attachment.p7s>

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