Thank you Alex for your comments and substantive suggestions. Team members, pls let me know if you have systemic disagreement with any of elements that Alex has put forward. In absence of notifications of disagreement, I will use Staff text with Alex's edits as a basis for our conversation tomorrow, 24 Oct 2pm UTC. Thank you JK On Wed, Oct 23, 2019 at 1:30 AM Alex Deacon <alex@colevalleyconsulting.com> wrote:
EPDP Colleagues,
Attached are IPC's comments and suggestions on the Accreditation building block language published on the wiki at https://docs.google.com/document/d/134Vryb2H5fYzC1B_451pfzCA1VHVtreF/edit .
Let me explain the main updates.
*A single Accreditation Authority vs. Multiple*
In my original Accreditation Framework and diagram presented in LA I defined a framework that assumed the existence of multiple Accreditation Authorities. Since then we have decided that ideally we want a single Accreditation Authority (run by ICANN) that can leverage one or more external/3rd party Identity Providers. This document (based on the doc submitted by Staff this afternoon) makes this assumption and accommodates for it. (I hope)
*Identifier Credential and Authorization Credential*
I added back the distinction (and definition) of an Identifier Credential and an Authorization Credential.
- An Identifier Credential is "static". It identifies an individual user in the system and is valid until it either expires or is revoked. For example my SSAD Identifier Credential would identity me to the system and convey my Name (Alex Deacon) and perhaps even my email address (alex@colevalley.consulting) and affiliation (Cole Valley Consulting). - An Authorization Credential conveys one or more access authorizations (also known as assertions or claims) that are associated with (and bound to) the Identity Credential. Authorization Credentials are more dynamic in nature an convey information that may change per request. (things like the purpose of the request, legal basis being asserted, compliance with laws/ToS/etc., etc. (See "Benefits of Accreditation f) for a list. )
The ability to associate a dynamic set of Authorization Credentials (assertions) on a per request basis simplifies the system and removes the need to issue and manage an identity credential for each purpose/basis/etc. combination. (users don't want to have to manage 12 or more different credentials to use the system) . Note that this is a "best practice" when building/designing authentication and authorization systems. Also note that the technology suggested by the TSG, OpenID Connect, supports the separation of Identity Credentials from Authorization Credentials.
*Revocation vs. De-Accreditation*
We were overloading the term De-Accreditation to apply to both Identity Credentials (associated with requestors) and the Accreditation Authority itself. I found this confusing so I defined the term "Revocation" to apply to Identity Credentials and De-Accreditation to apply to the Accreditation Authority itself. Revocation of an Identity Credential only impacts a single user of the system. (e.g. we revoked Alex's Identity Credential because he no longer works at Cole Valley Consulting - or got hit by a bus!) De-Accreditation of the Accreditation Authority impacts every credential managed by the Accreditation Authority (i.e. its the Nuclear Option when there is a major/catastrophic audit failure- everything fails and all credentials managed become null and void. )
*Accreditation is more than just Identification*
I've heard several folks state that Accreditation is only about Identification of requestors. In LA we made it clear that an Accreditation framework that only accomplished Identification was a waste of time. See my suggested update to the Benefits of Accreditation section which in addition to Identity lists: 1) management of Authorization Credentials, 2) How Identity Credentials and Authorization Credentials facilitate the decision to accept or reject the SSAD request, and 3) definition of a baseline code of conduct (based on EDPB guidance)
Please review and let me know if you have any suggestions. There is no doubt improvements that can be made - but hopefully this moves the ball a few steps in the right direction. Happy to walk thru this on the call on thursday morning.
Alex
___________ *Alex Deacon* Cole Valley Consulting alex@colevalleyconsulting.com +1.415.488.6009
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.