[Accred-Model] Version 1.6 of the Accreditation and Access Model

[Hollenbeck, Scott]

Fab, Annex I contains text with factual errors describing OpenID/OAuth-based client authentication. I shared some text with Mason last Friday, but it looks like this one paragraph was missed or my suggested edits were rejected:



"There is currently an Internet draft regarding the usage of federated client authentication (password and ID) based on OpenID and OAuth. However, theremay also be advantages to using digital certificates in conjunction with, or as an alternative method to federated client authentication because each method allows a client to be identified and authenticated for different client-server interactions. First, the access to RDAP does not have to rely on the availability of the identity provider which is a third-party required for federated authentication to work. A digital certificate can be used to identify and authenticate the client when establishing a secure connection to an RDAP server. Information encoded in the certificate can be used to determine if a client is authorized for access to an RDAP server. Second, the digital certificates provide non-repudiation due to the nature of Public Key Infrastructure (PKI). Third, digital certificates could provide flexible and scalable functionality. For instance, it could be used for enhanced access control such as role-based access control (RBAC) making decisions based on the attributes provided within the digital certificate. If the Internet community decides to adopt RBAC, there will be some application development work that would be required for RDAP. Fourth, identity providers are usually not under the tight scrutiny of an independent third-party auditor and are generally not used to processing a large amount of validation requests. Last but not least, when using digital certificates, the decision of whether or not to grant access is made entirely by the entity running the RDAP services instead of the identity provider which is a third party. Federated client authentication based on OpenID and OAuth can be used to identify and authenticate a client for access to specific registration data elements because this service is performed directly within the RDAP application layer as part of processing an RDAP query. Fine-grained attributes, such as the purpose of an RDAP query, can be encoded in the client's identity and shared with the RDAP server software that needs to determine if a client is authorized for access to specific data elements. Both approaches leverage trusted third parties (Certificate Authorities for digital certificates and Identity Providers for OpenID/OAuth) that can be used to make the secure attestations of a client's identity and attributes that are needed to ensure that a client is authorized to receive the data they are requesting."



Specifically:



"First, the access to RDAP does not have to rely on the availability of the identity provider which is a third-party required for federated authentication to work"



Digital certificates also depend on a third party in the form of the CA that needs to be queried to determine if a certificate has been revoked.



"Fourth, identity providers are usually not under the tight scrutiny of an independent third-party auditor and are generally not used to processing a large amount of validation requests"



A good bit of this document describes the procedures that would need to be put in place for accreditation to work. Those procedures, and the policies associated with accreditation, would need to include appropriate safeguards for ALL credential issuers, be they issuers of certificates or OpenID credentials. It would be more correct to strike this text given the focus of the rest of the document. I don't buy the "large volume" thing, either. Companies like Google and Facebook use OpenID technology today and it seems to be working just fine.



"the decision of whether or not to grant access is made entirely by the entity running the RDAP services instead of the identity provider which is a third party"



Identity Providers DO NOT make access control decisions. Information is shared with the Relying Party (RP), and it's the RP who makes access control decisions.



I'm willing to take another pass at this text if someone is willing to work with me.



Scott



From: Accred-Model <accred-model-bounces at icann.org> On Behalf Of Vayra, Fabricio (Perkins Coie)
Sent: Saturday, June 16, 2018 1:29 AM
To: 'accred-model at icann.org' <accred-model at icann.org>
Subject: [EXTERNAL] [Accred-Model] Version 1.6 of the Accreditation and Access Model



Attached for discussion and additional comment is version 1.6 of the Accreditation and Access Model.  This, following further comment and input from many parts of the community, is a much richer and robust model.  Notably, this version 1.6 contains new:



*       Annex D: Accreditation Approach for Intellectual Property Owners and Agents
*       Annex J: Lawful Bases for Access to WHOIS Data



Many thanks to those who made constructive contributions to further developing this model.



Thank you again for your input and support.



Fabricio Vayra | Perkins Coie LLP

PARTNER

D. +1.202.654.6255





  _____


NOTICE: This communication may contain privileged or other confidential information. If you have received it in error, please advise the sender by reply email and immediately delete the message and any attachments without copying or disclosing the contents. Thank you.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accred-model/attachments/20180618/b847ebfc/attachment.html>