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

[Achim Schlosser]

Hi,


I would agree with Ivan, again this scenario is only relevant in continuous offline-access scenarios where you basically would never or extremely rarely want to push the user through another authorization. The spec itself does not really get too much into persistence of user choices for claims for good reasons in general. 

If besides initial registration (that would pull more data via an authorization process) you would only want pull a subset of claims in downstream interaction I don't see why you would not just acquire a separate token with that specific scope for long term access in addition. 

That seems like a doable thing that address these use-cases without any additional complexity and would also be the right thing to do in terms of data minimization as you acquire access token with the correct scope as you need them. For registration you acquire a short term broad access token, for day-to-day you acquire a long term more restricted token.


Best

Achim 
On 12.03.20, 11:00, "Openid-specs-ekyc-ida on behalf of Torsten Lodderstedt 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:

    Hi,
    
    > 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,
    Torsten. 
    
    > 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