[WG-UMA] Protected Inbox Scenario

Joe Andrieu joe at switchbook.com
Thu Jan 14 17:18:48 EST 2010

Indeed, Iain has generalized the protected inbox to a more interesting 
area, at least for us VRM aficionados.

I think there are three elements of the scenario that we want under the 
user's control:

1. Intent
2. Access Control
3. Notification

(These terms can be improved, but I'll use them for now.)

1. Intent is about controlled release of an individual's intention data. 
That is, authorizing particular parties access to a protected resource 
which represents a statement of the user's interests or intention.
     Potential Intention data:
     a. Search Keywords
     b. Portable Context / Search Map
     c. Topics of Interest (from a lexicon rather than free form keywords)
     d. Filters (Keyword/Topic/Source)
     e. Classification of desired result types (products, events, 
locations, etc.)
     f. Intent-to-Buy (formerly known as a Personal RFP)

2. Access control is about controlling access to the incoming service 
endpoint for communications, i.e., the protected inbox.  I think from a 
UMA perspective, the important thing here is to actually throttle the 
incoming stream as much as is feasible.  For example, controlling 
frequency at the AM, but not attempting to analyze content to discern 
purpose. So, if "purpose" is part of the access control policy, then 
that would have to be self-asserted by the sender.
     Potential access control policy elements:
         Purpose (self asserted, "standard" values understood)
         Channel (may include channels outside UMA control loop)

3. Notification is about notifying the sender (once authenticated) about 
the access control policy they are currently authorized for. This is a 
means for an individual to tell a vendor the nature of messages they 
want to receive.  This is probably best served as a separate, modulated 
resource, where a vendor can request access to a resource containing a 
statement of relevant policy.

What I wasn't sure of when writing the Protected Inbox scenario was 
whether or not we wanted to accept this entire can of worms.  I focused 
on access control (#2), skipped #1 entirely, and suggested #3 might be 

Do we want to craft a scenario for "Permission Marketing" or something 
similar (I am not a fan of that term...), perhaps "Intention-driven 

FWIW, SwitchBook is essentially building an approach to 
"Intention-driven Communications", built around Search as the scope of 
intention and the browser as the channel for interaction. So, this is 
particularly intriguing and useful for us.


On 1/14/2010 7:19 AM, Eve Maler wrote:
 > Joe, great job on the scenario, and Iain, great additional thoughts! 
  (I have a few comments on the scenario as written -- nothing big -- 
and I'll try to send those by the end of this week.  The terminology 
seems to be generally correct on my first skim.)
 > Iain, regarding your twist on this scenario, it's good to know that a 
person's marketing-message preferences are ensconced in some countries' 
laws.  The "who I want to hear from" aspects seem to be pretty well 
covered in the the "Requester Identification" terms negotiation 
scenario, which I happened to revise last night (it still needs more 
 > http://kantarainitiative.org/confluence/display/uma/terms_id_scenario
 > The "what I want to hear about" aspect could involve a "promise"-type 
claim coming from the Requester ("this will be a once-monthly update, 
including occasional product coupons").
 > The "how I want to hear about it" might be implicit in having 
provisioned the vendor/Requester with the protected inbox endpoint (a 
URL), or there might be some more complicated dance involving a 
discovery service of some kind??
 > The "when I want to hear about it" could be either unilateral policy 
(disallowing incoming messages if they are more frequent than desired) 
and terms (asking the vendor/Requester to "promise" a certain 
frequency).  If the latter is used, auditing after the fact could 
determine if they're living up to their word.
 > The "who I don't want to hear from" could be done as unilateral 
blacklist policies around Requester identification, but could also be 
done dynamically as described in the scenario I linked above.
 > All in all, if we want to, I think we can probably include permission 
marketing as a motivation in the protected inbox scenario, and I can 
include the terms negotiation examples above into the relevant terms 
negotiation scenarios too.
 > What do you all think?
 >     Eve
 > On 13 Jan 2010, at 10:43 PM, Iain Henderson wrote:
 >> Hi Joe, co-incidentally I had asked Eve yesterday if there was room/
 >> time for a 'Permission Marketing' scenario....which there is, although
 >> it may be best to think about combining that with the Protected Inbox.
 >> Let's see.
 >> Where I was coming from with the Permission Marketing one, was that
 >> when a personal data store provider exists, there will be a set of
 >> data attributes under management that relate to:
 >> - who I want to hear from
 >> - what I want to hear about
 >> - how I want to hear about it (channel preferences)
 >> - when I want to hear about it
 >> - who I don't want to hear from
 >> Some of these data attributes have legal backing in European privacy
 >> law and in other geographies (Canada, Australia, NZ and no doubt a few
 >> others...and USA in respect to the phone suppression list). There are
 >> others that have industry good practices associated, the running of
 >> suppression files....less legally backed but an industry in itself.
 >> And that's all before we get to things like Change of Address
 >> registers, deaths registers and various other suppression approaches.
 >> So I guess i'm saying that as well as protecting the inbox (which
 >> deals with marketers/ spammers/ uninvited guests), would it also be
 >> possibly to have the above data attributes available by subscription
 >> to the people that I do want to hear from (in this case i'm thinking
 >> about the direct marketing I do want to receive, and not just through
 >> e-channels). Or that I cold manage my opt in/ opt out preferences in
 >> the one place rather than the current scenario whereby they are all
 >> over the place, with the data maintenance headaches that entails.
 >> Thoughts?
 >> Iain
 >> On 14 Jan 2010, at 06:03, Joe Andrieu wrote:
 >>> As requested, I've added the "Protected Inbox" scenario to the UMA
 >>> wiki at
 >>> http://kantarainitiative.org/confluence/display/uma/Protected+Inbox
 >>> It's a bit rough... in particular
 >>> (1) I'm not sure I'm using the correct terminology in the
 >>> diagrams... we
 >>> might want to update that to be more in sync with the terms we are
 >>> using
 >>> in the specification and
 >>> (2) I included some aspects of this that I think are more properly
 >>> deferred to a future UMA (labelled as such).  I'm not sure how we
 >>> might
 >>> note these "future" aspects, but I didn't want to lose the
 >>> forward-looking opportunities.
 >>> Feedback is appreciated. The diagrams are easy to update, so just
 >>> let me
 >>> know what changes you want.
 >>> Cheers,
 >>> -j
 >>> --
 >>> Joe Andrieu
 >>> joe at switchbook.com
 >>> +1 (805) 705-8651
 >>> http://www.switchbook.com
 >>> _______________________________________________
 >>> WG-UMA mailing list
 >>> WG-UMA at kantarainitiative.org
 >>> http://kantarainitiative.org/mailman/listinfo/wg-uma
 >> Iain Henderson
 >> iain.henderson at mydex.org
 >> This email and any attachment contains information which is private
 >> and confidential and is intended for the addressee only. If you are
 >> not an addressee, you are not authorised to read, copy or use the e-
 >> mail or any attachment. If you have received this e-mail in error,
 >> please notify the sender by return e-mail and then destroy it.
 >> _______________________________________________
 >> WG-UMA mailing list
 >> WG-UMA at kantarainitiative.org
 >> http://kantarainitiative.org/mailman/listinfo/wg-uma
 > Eve Maler
 > eve at xmlgrrl.com
 > http://www.xmlgrrl.com/blog

Joe Andrieu
joe at switchbook.com
+1 (805) 705-8651

More information about the WG-UMA mailing list