[WG-IDAssurance] Relying Party Guidelines

Thu Feb 3 09:53:08 EST 2011

The term used by the GSA and others to generically refer to SAML SP is Relying party.
ICAM SAML 2.0 Web Browser SSO Profile

openID and Information Card (IMI) both use the RP terminology having come along more recently.

John B.
On 2011-02-03, at 11:28 AM, Clowes Neil wrote:

> Ben
>  
> Thanks for this – despite the headache!
>  
> Am I right in thinking that the Service Provider would be a relying party because he is relying on, for example, an assertion by an authentication broker as to identity?
>  
> Neil
>  
>  -----Original Message-----
> From: wg-idassurance-bounces at kantarainitiative.org [mailto:wg-idassurance-bounces at kantarainitiative.org] On Behalf Of Ben Wilson
> Sent: 02 February 2011 5:53 AM
> To: WG-IDAssurance at kantarainitiative.org
> Subject: Relying Party Guidelines
>  
> Here is an initial thought piece, just to serve as a starter (appetizer) for people to look at and give me feedback / direction on.  I haven’t had time to expand on my thoughts about privacy protections against abuse by RPs or risk assessment to be performed by RPs, which I assume are also topics that we should cover.   Other thoughts that came to me after I closed the document and before I sent this email are included below.   I/We could build on this starting piece by reviewing relying party discussions found in the documents listed below (most sourced from the PKI world, but capable of being broadened and modified for the Kantara world).   In addition to Kantara framework documents, here are some other examples:
>  
> ABA Digital Signature Guidelines and PKI Assessment Guidelines
> FICAM Trust Framework Provider Adoption Process, Identity Scheme Adoption Process and Implementation Guidance for Relying Parties Using the Common Policy Root (plus pull in everything that mentions “relying party” on idmanagment.gov)
> Pull out the GSA ACES “Qualified/Recognized/Authorized Relying Party” concept, the interagency and eAuth Relying Party Agreement and other documents from eAuth
> Review Tom Smedinghoff’s CA Liability Analysis, the Australian National Electronic Authentication Council scoping study (Aug. 2000) and NOIE Report (May 2002), NIST SP800-63, and OMB 04-04.
> Collect various definitions of “relying party” available from the above resources
> Discuss insurance, guaranties and warranties of identity/attributes and “guaranteed” reliance values provided as a commitment, incentive or risk mitigant to relying parties
> Review whether / how the rights and obligations of relying parties might vary depending on Assurance Levels
> Review what reps , warranties, liabilities, etc. cannot be waived, abrogated because of law, public policy, Kantara policy, cross-federation policy, etc.
> PRIVACY – How is information handled?  What requirements must a Relying Party meet to become “qualified” – certified or otherwise trusted not to abuse any PII that might be disclosed?  (e.g. PCI-DSS)
> Can an IdP, CSP, federation member, etc., prohibit types of reliance, if so, how, and what are the effects?  (e.g. assumption of risk by relying party, waiver of potential claims, etc.)
> What are the relying party software developer’s responsibilities to understand and program systems to properly handle the trust / security mechanisms used?   What product certification steps are in place or should be in place?
> Review handling of risks through tightly-worded express contractual frameworks (e.g. IdenTrust relying participant / relying customer) vs. publication of terms and conditions on web site and incorporation by reference (e.g. Ts&Cs constitute an “offer,” which is “accepted” and binding on a relying party upon use of service, etc.), etc.
> Explore various scenarios, myths, misconceptions, etc. (to be developed)
> Other thoughts to add or gaps?  I’m sure there are plenty.
> Ben
>  
> Benjamin T. Wilson, JD CISSP 
> General Counsel and SVP Industry Relations
> DigiCert, Inc.
> <image001.gif>
> Online: www.DigiCert.com
> Email: ben at digicert.com
> Toll Free: 1-800-896-7973 (US & Canada)
> Direct: 1-801-701-9678
> Fax: 1-866-842-0223 (Toll Free if calling from the US or Canada)
> The information contained in this transmission may contain privileged and confidential information. It is intended only for the use of the person(s) named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. Thank You
>  
> 
> This email was received from the INTERNET and scanned by the Government Secure Intranet anti-virus service supplied by Cable&Wireless Worldwide in partnership with MessageLabs. (CCTM Certificate Number 2009/09/0052.) In case of problems, please call your organisation’s IT Helpdesk. 
> Communications via the GSi may be automatically logged, monitored and/or recorded for legal purposes.
>  
> **********************************************************************
> 
> This email and any files transmitted with it are private and intended
> 
> solely for the use of the individual or entity to whom they are addressed.
> 
> If you have received this email in error please return it to the address
> 
> it came from telling them it is not for you and then delete it from your system.
> 
> This email message has been swept for computer viruses.
> 
> 
>  
> **********************************************************************
> 
>  
> 
> The original of this email was scanned for viruses by the Government Secure Intranet virus scanning service supplied by Cable&Wireless Worldwide in partnership with MessageLabs. (CCTM Certificate Number 2009/09/0052.) On leaving the GSi this email was certified virus free.
> Communications via the GSi may be automatically logged, monitored and/or recorded for legal purposes.
> _______________________________________________
> WG-IDAssurance mailing list
> WG-IDAssurance at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-idassurance

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-idassurance/attachments/20110203/796f0e40/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
Url : http://kantarainitiative.org/pipermail/wg-idassurance/attachments/20110203/796f0e40/attachment-0001.bin 