- changed component to SIOP
SIOP requires user consent
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)
-
-
What in particular would you like to see outside of Section 3.1.2.4 and its existing MUST?
-
+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.
-
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.
-
+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.
-
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.
-
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.
-
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?
-
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)?
-
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.
-
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:
- holder == subject
- 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?
-
I agree with @David Waite ’s observation in [Openid-specs-ab] A Case for SIOP and Trust Frameworks that details of consent processing should be part of each trust framework that SIOP belongs to.
We could include a non-normative text in the spec emphasizing the importance of consent (in a sense of a “technical“ action) in particular in SIOP model.
-
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.
-
@Kristina Yasuda Agree.
-
- changed status to open
-
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.
-
reporter I believe that consent in siop should not be optional.
-
It is *not optional* as has been pointed out in the comment above (https://bitbucket.org/openid/connect/issues/1215/siop-requires-user-consent#comment-60471707), and unless there is a compelling reason to modify section 3.1.2.4 of OIDC for a SIOP flow, we should close this issue.
-
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.
-
Can you please propose a text and do a PR?
-
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.
-
- changed status to resolved
Thank you very much Tom for putting your time and energy thinking about this important issue! Looking forward to alternative approaches.
- Log in to comment