[Gnso-epdp-team] IPC Comments on the Accreditation Building Block.

Wed Oct 23 15:24:45 UTC 2019

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 at 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 at 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 at colevalleyconsulting.com
> +1.415.488.6009
>
> _______________________________________________
> Gnso-epdp-team mailing list
> Gnso-epdp-team at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20191023/e5dfe0ac/attachment-0001.html>