[WG-UMA] Protected Inbox Scenario
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
2. Access Control
(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,
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
> 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?
> 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.
>> On 14 Jan 2010, at 06:03, Joe Andrieu wrote:
>>> As requested, I've added the "Protected Inbox" scenario to the UMA
>>> wiki at
>>> 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
>>> 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
>>> 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.
>>> Joe Andrieu
>>> joe at switchbook.com
>>> +1 (805) 705-8651
>>> WG-UMA mailing list
>>> WG-UMA at kantarainitiative.org
>> 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
> Eve Maler
> eve at xmlgrrl.com
joe at switchbook.com
+1 (805) 705-8651
More information about the WG-UMA