[WG-UMA] Protected Inbox Scenario

Eve Maler eve at xmlgrrl.com
Thu Jan 14 10:19:18 EST 2010

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 improvements):


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.
> 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

More information about the WG-UMA mailing list