[gnso-rds-pdp-wg] Taxonomy: Authorization and Authentication

[Carlton Samuels]

Whaddya know, should've read thru the entire thread!

Lisa would have caught this, if only because she counseled similar 'stop
and define' on account of similar to-and-fro on these meanings in the EWG.

Way to go Lisa.

-Carlton

-Carlton


==============================
Carlton A Samuels
Mobile: 876-818-1799
*Strategy, Planning, Governance, Assessment & Turnaround*
=============================

On Wed, Jul 20, 2016 at 4:11 PM, Lisa Phifer <lisa at corecom.com> wrote:

> Mark,
>
> One more "A" term to add to the mix: Accreditation.
>
> The EWG recommended authentication based on credentials issued to *accredited
> RDS users*. While basic registration data would remain publicly
> available, the rest would become accessible only to users who authenticated
> themselves, stated a purpose, and agreed to be held accountable for
> appropriate use. Only the requested data elements which policy authorized
> for that user+purpose would then be disclosed (for example, in an RDAP
> response).
>
> This raised very tough questions around how RDS users might be accredited,
> who could realistically accredit them, and (for each purpose and type of
> user) which data elements they might be authorized to access. You can find
> thinking on this in Section IV(c) of the EWG's report and in the EWG's Registration
> Directory Service User Accreditation RF
> <https://community.icann.org/download/attachments/45744698/EWG%20USER%20ACCREDITATION%20RFI%20SUMMARY%2013%20March%202014.pdf>I
> which gathered technical input. Ultimately, the EWG flagged "accreditation
> bodies and policies for RDS user communities" as an issue needing to be
> more fully addressed (pg 121).
>
> I thought you might find this past work of interest - in particular, the
> notion that RDS authorization might depend on more than who you are,
> including factors such as stated purpose, whether you have been accredited
> for that purpose, and access policies for each data element you request.
>
> Best, Lisa
>
>
>
> At 12:19 PM 7/20/2016, Mark Svancarek via gnso-rds-pdp-wg wrote:
>
> Content-Language: en-US
> Content-Type: multipart/alternative;
>
> boundary="_000_CO2PR03MB2135BFFF802A5C6DC446A4ECD1080CO2PR03MB2135namp_"
>
>
> We use these terms a lot and we also use phrases which mean things similar
> to these terms.  I’d like to explicitly define them and I encourage all to
> use them as defined so as to be clear and concise.  I think it will help.
>
> ·         *Authentication* = based on the credentials you have shared
> (e.g. user name, password, SMS response, smart card, etc.), we know
> * who you are *·         *Authorization* = based on who you are, you are
> allowed to access specific resources and those resources only, i.e. we
> define
> *what you can do *
> If you want to be extra-nerdy:
>
> ·         Authentication can be abbreviated “*authN*”
> ·         Authorization can be abbreviated “*authZ*”
> ·         Authentication and Authorization together can be referenced as “
> *authX*”
>
> I hope that’s useful.
>
> /marksv
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>
>
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20160720/3a777936/attachment.html>