1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. connect
  4. Issues

SIOP requires user consent

Issue #1215 resolved
Tom Jones created an issue

In OIDC consent was optional. I don’t believe that idea should apply to SIOP. Consent is always required. It might occur in different forms on (or through) the wallet. It might be buried in some user gesture, It might be remembered in some refresh token. But it is always required.

Comments (22)

  3. Nat Sakimura

    +1 @David Waite

    In OpenID Connect Core, “Consent” is a MUST if consent is an appropriate lawful basis for processing, though implementations have some freedom in the method of obtaining it. It may have been previously obtained on a sheet of paper and a wet-signature before the transaction.

    At the same time, I need to point out that having the end-user press a button does not equal to obtaining valid consent. There are a whole lot of conditions for consent to be valid and informed other than just pressing a button.

  4. Tom Jones reporter

    Let me give two examples of administrative consent that make the point that contemporaneous consent is required.

    1> employee signs an employment agreement which explicitly provides consent to void all privacy concerns and strips them of all legal remedies.

    2> patient signs a consent to even see a physician which explicitly gives the physician’s practice consent to share health data with any other covered entity.

    I want to strip administrative consent (“wet signature”) from SIOP as inappropriate for a self-issued identifier. I want to show the user what data is requested and for what purpose as close to the actual transaction as possible. There are some open issues, for example within a session should be appropriate. But what i don’t want to allow is blanket consent w/o displaying the data requested and purpose to the user.

  5. Kristina Yasuda

    +1 @David Waite

    First, I think we all agree that consent is a MUST in SIOP since Section 3.1.2.4 of Core applies. To decide whether SIOP model needs an additional consent requirement, I think we should go back to what is specific to SIOP.

    What SIOP does is it allows the users to use OPs that they control. Since sharing data is part of the OP functionality, user controlling an OP would imply that the user also controls what data SIOP shares with the RP. Therefore showing what data is requested is already inherent to the SIOP model itself.

    Initial implementations already show to the user what data is requested, but given that this is very likely to be use-case specific, I would prefer adding a guiding text on this instead of making it a must.

    Now regarding “purpose“, sounds like what you mean is showing to the user “where the RP is planning to use the received data”. This is not SIOP specific. If we are to add parameter “purpose“ in the request and make it required, it should be considered for the entire connect.

    Overall, as long as consent itself is a MUST (which is already the case), concrete HOWs and additional requirements tend to be dependent more on the applicable regulations, implementations and the use-cases rather than another MUST in a technical specification.

  6. Tom Jones reporter

    I reject the idea that the how is not important. I point to the problem of presentation exchange as the result of leaving explicit human consent out of the equation. The result will be standards that human beings reject.

    There was another discussion off thread. The core issue is whether consent belongs in ODIF at all. I strongly believe that w/o contemporaneous user consent to xfer user private data the SIOP process is not a user-centric approach. The question for OIDF then becomes whether the protection of the user is in scope. My assertion is that it should be in scope.

  7. Kristina Yasuda

    If you read what I am saying carefully, I am not saying it is not important, I am saying it is either already addressed or should be addressed elsewhere, because it is important.

  8. Tom Jones reporter

    Oh i read what you said - It’s not our problem. That is the same thing that Daniel said about PX - it’s not his problem. I want the problem solved, if not us - Who? If not now - When?

  9. Alen Horvat

    What is the exact definition of the “User Consent“?

    Legally-binding consents depend on jurisdictions (I guess this is out of the OIDF scope, or?)

    Does the user consent refers to a “technical“ action (e.g., making user aware of what information he/she shares and asking user for a confirmation)?

  10. Tom Jones reporter

    that’s a reasonable definition. ==> making user aware of what information is requested and asking user for a confirmation. (In a presentation exchange is is unclear how to do this)

    But he aware of the problem of defining user / RO / subject / holder that is introduced in w3c and in GNAP --- the consent does need to come, ultimately, from the subject of the information (delegation may be involved.)

    And caching of consent could also be addressed as needed.

    ‌

  11. Alen Horvat

    If the definition of user consent (in this context) making the user aware of what information is requested and asking the user for a confirmation is acceptable, we need to consider two cases:

    1. holder == subject
    2. holder != subject

    In both cases, the consent needs to come from the subject.
    Should the consent be explicit (as a user I receive a text and I need to select “I agree“) or implicit?

    Consent processing:

    • Should the consent be processed? If yes, by whom? Wallet?
    • If the subject does not consent, should the “wallet” or the holder cancel the process?

    ‌

  13. Tom Jones reporter

    I want a normative statement that subject consent is required. I dislike the admin cop out in oidc.

    I want to know if siop will consider holder to be a defined term.

    If holder is a defined term i want to be clear how delegation from subject to holder is expressed by the holder – sorry for lack of detail but this needs to be thought thru in more detail.

    BTW - i agree in general with DW’s statement.

  16. Michael Jones

    Unless there’s a compelling reason to make the consent logic different in SIOP than the rest of OpenID Connect, we should close this issue on that basis.

  19. Tom Jones reporter

    I don’t know why you accept others saying it is not optional. Read the spec - specifically read 3.1.2.4 - as one method is “via administrative consent”. I want that to be unacceptable for SIOP.

  21. Tom Jones reporter

    I spent a great deal of time thinking about this issue and decided to close the issue because i cannot imagine any way forward as neither a data model nor a protocol spec can possibly define a behaviour that users can understand. Especially when I looked at wallet behaviours, it is really the wallet spec that will determine whether any of this activity will result in an experience that users will accept. In other words, any attempt to view siop as an overlay for OIDC is wrong and doomed to failure. I will try to propose a different approach.

  22. Kristina Yasuda

    Thank you very much Tom for putting your time and energy thinking about this important issue! Looking forward to alternative approaches.

  23. Log in to comment
Assignee
–
Type
enhancement
Priority
major
Status
resolved
Component
SIOP
Milestone
–
Version
–
Votes
0
Watchers
7
Jira Software: the preferred issue tracker for Bitbucket. Join the team!