[WG-IDAssurance] What to call a Relying Party in terms of aTrust Framework

[Richard G. WILSHER (Zygma)]

I would say emphatically that the roles must drive the terms, otherwise the
terms are too nebulous and one cannot be specific about the consequences or
obligations of the entity when in that role.

RGW


-----Original Message-----
From: wg-idassurance-bounces at kantarainitiative.org
[mailto:wg-idassurance-bounces at kantarainitiative.org] On Behalf Of Mark
Lizar
Sent: 09 March 2011 18:46
To: Rainer Hörbe
Cc: IA WG
Subject: Re: [WG-IDAssurance] What to call a Relying Party in terms of
aTrust Framework

Thanks Rainer,

I think I now have a better sense of the complexity the IAWG is  
working with. Would the roles then drive the terms ?


On 9 Mar 2011, at 17:43, Rainer Hörbe wrote:

> Mark,
>
> The roles in the sense of DPD depend on the use case and legal  
> positions of the parties. Also, it is important to have the role  
> "recipient", the person who is granted access to the subject's data.
>
> In the typical SP-centric use case the RP is the controller for the  
> data provided by its service. The IdP is controller or processor for  
> the PII related to the identity management, depending on the role of  
> the registration authority. The subject (= user) is the recipient.  
> The data subject does not have a role in the basic use case.
>
> In a UMA-use case this might be different. The user is both data  
> subject and controller, the RP is processor, IdP either controller  
> or processor, as above.
>
> - Rainer
>
>
> Am 09.03.2011 um 18:04 schrieb Mark Lizar:
>
>>
>> Hello All,
>>
>> In the data protection world a relying party would be called a
>> 'Processor' an Identity Provider would be called a 'Controller' and a
>> service user would be called the 'Data Subject or Principle'.
>>
>> I think these terms map quite well.  As well.  I think there should  
>> be
>> a level of Processing Assurance = eg RP assurance that certifies the
>> highest standard of data protection regulation in the jurisdictions  
>> it
>> will federate.  From this point a federation contract and policy
>> mapping should then be entertained for higher level assessment  
>> criteria.
>>
>> For all levels a privacy framework should entail auditing and the
>> passing of privacy preferences/profile to the relying party
>> (processor) from the Identity Provider (controller).
>>
>> My 2 cents.
>>
>> Mark
>>
>>
>>
>> _______________________________________________
>> WG-IDAssurance mailing list
>> WG-IDAssurance at kantarainitiative.org
>> http://kantarainitiative.org/mailman/listinfo/wg-idassurance
>

_______________________________________________
WG-IDAssurance mailing list
WG-IDAssurance at kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-idassurance