presentation-exchange
presentation-exchange copied to clipboard
decentralized-identity
support terms of service
as raised in #18
TODO: A demand for proof should be able to include terms of service that the verifier commits to upon receipt of the data. We don't need to define that in great detail. I know that TOS was a rat hole in VC spec work. But we need to allow for it, or else the spec is unusable in many situations.
Good idea, our folks have something similar, called consent in their one-off formats in use today. Can someone propose a PR that covers TOS, consent statements, etc.?
@symorton We have a consent field in our MSFT-centric data format, and this seems very close to that in terms of a feature request. Do you want me to add something to the PE spec that can cover these two related needs?
I remember discussing this in the context of GDPR. In our (Workday's) flow we have a reason field that must be provided when requesting data. IANAL but it seems like an easy step to include a TOS/Reason field to facilitate compliance.
Feeling of the WG is that this is out of scope for the PE data model, but we may want to describe why and what an implementation might do orthogonally to fulfill this need.
I am 100% not a lawyer, but as I understand it, consent and purpose are two separate GDPR values-- you can consent to giving a company X piece of data, in accordance with Y terms of service, for Z purpose. That company can turn around repurpose X without breaking the terms of service Y or your consent, but this repurposing is also (separately) something you'd be liable for under some interpretations of GDPR. In the GDPR OAuth work I've seen ( @mehdim , care to chime in?), they are separate parameters sometimes but not always used in combination...
I wasn't a participant in the discussion as to why purpose made it in but something like TOS did not. Could someone summarise to me the rationale of the group?
Our presentation definition (equivalent) contains a terms - it must be a uri. Submission can only occur if consent is obtained.
On a related note it also contains an optional duration field which is used to clearly inform the holder the period of time that the credentials will be retained by the verifier
