Child pages
  • UST Intentcasting V.2 UX and Human Readable
Skip to end of metadata
Go to start of metadata

UST:  Intent Casting V.01 UX and Human Readable term

Project: develop a term for defining what it means to limit the use of an individual's data for an intent cast.

This is the current diagram with notes below and questions about this term.




PREAMBLE:  The User submitted term shown here creates an opportunity for individuals to share their terms with entities about how they wish to be treated. This effort is meant to describe human, legal and machine readable versions of a comprehensive term along with additional information for agents who might implement this term for individuals as well as for entities who might see, accept or refuse the term.  {{ Information is defined as personal information provided by the individual about themselves. Data + Meaning = Information. The observer creates meaning (or observer is "informed by" the data), and then can be assigned duties. Information not collected from a person does not by definition constitute personal data. }}

Implementation questions and issues:

  1. Implementations should assume the term applies to specific data.
  2. Who will receive data? marketplaces? exchanges? by agents? will the data be anonymized?
  3. Should guidance for Bob state that no personal data should be shared, only anon data on behalf of Alice?
  4. Can Alice turn off an intentcast? Stop the flow of info? Mute a request?
  5. Can Alice's information be removed entirely from Bob?
  6. Audits? How will we know this term was followed? Delegation tokens? Power of Attorney tokens?


TERMS AGREEMENT:  {{ Information can only be shared with those parties who first agree to abide by these terms.  Any sharing of information with a party that has not first agreed to these terms is a violation of these terms. }}

PARTIES: describes the terms for sharing information with entities by individuals.


SHARING:   My personal information shared and what I do will be kept between me and the entity. When my intentcast request is fulfilled, any personal or other information shared with other parties for my purpose specified will be kept to a minimum for the particular context. 

{{Information shared by an individual (the “1st party”) for their intentcasts are not permitted to be shared by the 2nd party with any other parties except at the minimum to fulfill a purchase for the purpose fulfillment.}}

Implementer guidance: The intentcast request, anonymized could be shared with a 3rd party partner and results passed back to 1st party, if it complies with the purpose use the 1st party has specified. However, no other personal information may be passed between 2nd and 3rd parties in order to find results to intentcast request. Once a purchase is agreed to, minimum personal information should be shared. For example, the purchase would require a name and payment information. That should go to the seller. Separately, just shipping address information should go to the shipper.


3rd Party Limited: You can share my intentcast and my Personal Information to fulfill only those intension(s). Only those 3rd parties providing a service or information for my purpose can see my personal data.

{{ Information ??? Legal to fill out? }}

3rd Party Unlimited: Any third party that gets my intentcast will receive my Personal Information.

{{ Information ??? Legal to fill out? }}


DURATION: describes the terms for retaining information by entities about individuals. {{ Legal: Add language referring to laws or contracts, defining 3rd party jurisdiction, to limit this from abuse. }}

CHOICE:   One Time:  My intentcast will seek responses until I've purchased the intended item. Once I've found the item, or abandoned the search, I'm finished.

{{ Information ??? Legal to fill out? }}


Forever until further notice: My information will be kept as long as I continue to choose this term, unless required by law or contractual obligation. If I change to another lesser term, my new term will be followed.

{{ Information about an individual can be retained indefinitely by the 2nd party, unless and until the 1st party notifies the 2nd party they have made an alternate selection for duration. }}


Right Now:  When I log out of my session, whether or not I purchase, I'm finished.

{{ Information ??? Legal to fill out? }}


PURPOSE: describes the purpose for use of individual's information provided or about actions they take.   {{  }}

CHOICE:  Site and App UseMy information will be used for providing responses for my intentcast, or for enhancing / providing the service, but not other purposes without my permission.

{{ Information about an individual may be used beyond the transaction for which it was collected or generated, but only with respect to the operation [or further development?] of the site or app over which such original transaction occurred and not for any other secondary uses by the 2nd party or other parties. }}



3rd Party Marketing +:  3rd Parties may use my information to share additional marketing with me.
{{ Information ??? Legal to fill out? }}

Transaction: My personal information can be used for a purchase, and once all is complete, after legal requirements are fulfilled, my information will be {{ deleted }} or {{ given to me in x form }} .


{{ Information ??? Legal to fill out?  }}

ERASURE: describes the terms for removal of personal information by entities about individuals. {{ Add language referring to laws and contracts to limit this if data retention is required by law. }}


Keep: My information stored by an entity will be keep for the sharing, purpose and duration I've specified with my intensions in my term.

{{ Information ??? Legal to fill out?   }}


Erasing data and/or consent: My information use by an entity can be erased when I signal this to occur, unless required by law or contractual obligation. If I change my mind, I can reshare my information under the terms in this agreement at my will.

{{ Information ??? Legal to fill out? }}




  • No labels


  1. I'm thinking we should start to think about mapping User Submitted Terms to Consent Receipts. Not all of the elements will map of course, but where they refer to the same kind of information (like purpose) then Alice should be able to get back a receipt that matches her submitted terms.

  2. In discussions, we talked about duration. Should there be a 'fulfilment cast' to terminate an intent cast to stop being bugged after purchase made?

    On the technical side, the question for the machine readable form is what will that be? A browser header? A JSON file? Should it be modelled/compatible with the Consent Receipt?

    On the server side, do we need to think about modules/extensions to handle this? Of this out of scope for CISWG and/or Kantara? (referral to Mr. Lurking)

    Suggestion for wider group discussion about how to reconcile UST/CR so that the technical modes are compatible.

    Colin suggests John to write a new draft project scope.

    Input/feedback/comment from (Jim on the call, will take away) and JLINC (Colin has seen intent casting demo) - two months to VRM day at IIW, where this might fit for discussion, and demo on demo day at IIW.

    1. I'd say the fulfillment cast is covered by duration, although there will be more evolved versions of intentcasting that will cover different scenarios, eg. regular purchases. We should not think we're covering anything but the minimum viable variant here.

      I don't think we should get into the technical side on the server, we need to build intentcasting as omnichannel, and web is probably one of the least good - people will cast, review, query, negotiate and ultimately buy (or not) over many separate sessions.