RE: Question to the FedID CG re: FPS

BTW In researching the GVS proposal I looked at two methods of validation.


  1.  EV certificates<https://cabforum.org/extended-validation/> – there are issues<https://en.wikipedia.org/wiki/Extended_Validation_Certificate#Criticism> which the GVS proposals recognises. However, it is worth considering that EV certificates have been developed over a long period or time and are deployed and available today. What makes W3C believe it can do a better job defining a solution? Why would a technical standards group seek to define business and legal processes? The IEE in FPS seems to be “reinventing the wheel”.
  2.  Notaries<https://www.thenotariessociety.org.uk/pages/what-is-a-notary> – a long established and regulated profession for establishing authenticity. Notaries are used by many of the businesses participating in this discussion. If notaries provide the level of certainty needed to enter into binding international legal agreements, why would they not have a role here?

Others can be added. I’m not familiar with R&E federation. Could this be applied to establishing legal identity?

Whilst there is free will in the world then there will always be bad actors. We will make a lot more progress improving the status quo if we acknowledge this rather than seeking to find absolutes solely in the field of engineering.

We would also make more progress if we stopped using the terms first and third party. Movement for an Open Web (MOW), a group I’m Director of, produced a short animation<https://movementforanopenweb.com/animation-an-open-web-for-everyone/> explaining how these terms and their application to privacy is harmful. MOW has also published analysis<https://movementforanopenweb.com/in-depth-analysis-of-googles-first-quarterly-report/> into Google’s first quarter report covering their commitments with the UK CMA. Google’s proposals must be made with reference to GDPR and the data controller and processor requirements. First and third are meaningless as the CMA and ICO advised in 2021<https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/987358/Joint_CMA_ICO_Public_statement_-_final_V2_180521.pdf>.

James

[1] Data is sometimes categorised according to the relationship between the party collecting
and processing it and the individual or circumstance it relates to:

• First-party data: data that is collected by a business through direct interaction with an
individual providing or generating the data. For example, data collected by an online
retailer regarding purchases made by consumers on its site.

• Third-party data: data collected by a business not in direct interaction with the individual
providing or generating the data, for example, through business partners. Digital firms
that do not have a direct relationship with users frequently rely on third-party data.

The boundaries between first and third-party data according to the above definition are not
always clear, particularly when large companies own a variety of businesses, some of which
have a relationship with the user and some of which do not.

Both first-party and third-party data as defined above can include personal and non
personal data. Whether information is personal data depends on whether it relates to an
identified or identifiable individual. There is no explicit reference to the distinction between
first-party and third-party data in data protection law.

The descriptions of ‘first party’ and ‘third party’ are also used (though with a different
meaning) in the context of cookies and similar technologies,10 which collectively form the
key means by which information (including personal data) is collected and disseminated in
online advertising. A cookie is generally identified as being first-party if the domain of the
cookie matches the domain of the page visited and as being third-party in instances where
the domain of the cookie does not match the domain of the website. This is not a rigid
distinction. Some functions typically delivered through third party cookies can be done via
first party cookies, even if a third party’s code and associated service is still involved.

The rules on the use of cookies and similar technologies are specified in Regulation 6 of
the Privacy and Electronic Communications Regulations 2003 (as amended) (‘PECR’), and
oversight of these rules is one of the ICO’s regulatory functions. PECR provides more
specific rules than the UK GDPR in a number of areas such as cookie use. It is also
important to note that PECR’s provisions in this area apply whether or not personal data is
processed.

From: Nicole Roy <nroy@internet2.edu>
Sent: 01 June 2022 19:52
To: James Rosewell <james@51degrees.com>
Cc: Tim Cappalli <Tim.Cappalli@microsoft.com>; Brian May <bmay@dstillery.com>; Brian Campbell <bcampbell@pingidentity.com>; Heather Flanagan <hlf@sphericalcowconsulting.com>; public-fed-id@w3.org
Subject: Re: Question to the FedID CG re: FPS

I just thought of a problem with the GVS proposal. EV certificates are notoriously hard to procure, especially when compared to something like ACME. Many research communities are *not* legally-official entities, and therefore cannot meet the requirements imposed by the CA/Browser Forum for the issuance of EV certs, and even if they could, most likely wouldn’t pursue EV certificates because they are so difficult to obtain and keep renewed. That entire mechanism is also needlessly duplicative of trust practices which are articulated by well-established and enormous trust communities like the R&E federation space (see: https://met.refeds.org/)

Nicole


On Jun 1, 2022, at 12:22 PM, Nicole Roy <nroy@internet2.edu<mailto:nroy@internet2.edu>> wrote:

This is good to see. From reading your comment at the top of that PR, at face-value, it does seem to address “Third-Party Federation” use cases as termed by Tim. The devil is in the details.

Best,

Nicole


On Jun 1, 2022, at 12:03 PM, James Rosewell <james@51degrees.com<mailto:james@51degrees.com>> wrote:

FYI GDPR Validated Sets proposal uses data protection law to address both scenarios and would work well for FedID. PR to modify FPS to GVS is here<https://github.com/privacycg/first-party-sets/pull/86>.

Google are bound by their CMA commitments to work in all matters privacy to GDPR so presumably support GVS even if they’re yet to say so.

From: Tim Cappalli <Tim.Cappalli@microsoft.com<mailto:Tim.Cappalli@microsoft.com>>
Sent: 01 June 2022 18:53
To: Brian May <bmay@dstillery.com<mailto:bmay@dstillery.com>>; Brian Campbell <bcampbell@pingidentity.com<mailto:bcampbell@pingidentity.com>>
Cc: Nicole Roy <nroy@internet2.edu<mailto:nroy@internet2.edu>>; Heather Flanagan <hlf@sphericalcowconsulting.com<mailto:hlf@sphericalcowconsulting.com>>; public-fed-id@w3.org<mailto:public-fed-id@w3.org>
Subject: Re: Question to the FedID CG re: FPS

At OSW, I proposed two new terms to help with these discussions: Same-Party Federation and Third-Party Federation (there is debate over these terms, but I stand by them in the context of these browser changes).

Same Party Federation would be, for example, Google Maps, Gmail, YouTube, and Google Sign-In, or Disney, Hulu, ABC, and ESPN.

FPS will solve many Same Party Federation issues. It will not help with Third-Party Federation (unless things like CNAMEs are used).


<image001.png>


tim

From: Brian May <bmay@dstillery.com<mailto:bmay@dstillery.com>>
Date: Wednesday, June 1, 2022 at 13:36
To: Brian Campbell <bcampbell@pingidentity.com<mailto:bcampbell@pingidentity.com>>
Cc: Nicole Roy <nroy@internet2.edu<mailto:nroy@internet2.edu>>, Heather Flanagan <hlf@sphericalcowconsulting.com<mailto:hlf@sphericalcowconsulting.com>>, public-fed-id@w3.org<mailto:public-fed-id@w3.org><public-fed-id@w3.org<mailto:public-fed-id@w3.org>>
Subject: Re: Question to the FedID CG re: FPS
For anyone not in the Slack channel, Tim Cappalli also posted this article<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ghacks.net%2F2022%2F05%2F23%2Fbrave-joins-mozilla-in-declaring-googles-first-party-sets-feature-harmful-to-privacy%2F&data=05%7C01%7Ctim.cappalli%40microsoft.com%7Cff98ac5eeea14faa8f9608da43f546e7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637897018009093866%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2Fk6p9biX6v86h1axYFwcm7Go1hHrNhIpXS3MTeUMLkY%3D&reserved=0> in which Brave describes FPS as harmful to privacy.

My general sense from across the groups I participate in is that FSP, as currently conceived, won't be supported as a standard. Given that, I think the question is whether there would be sufficient availability for it to be a viable dependency and I think the answer is no.

I also think, given my understanding of the Federated Identity use-case (which admittedly isn't deep) that FPS provides much more leeway than is necessary and that a specifically tailored solution would be more appropriate and easier to get accepted by browser vendors.

On Wed, Jun 1, 2022 at 12:48 PM Brian Campbell <bcampbell@pingidentity.com<mailto:bcampbell@pingidentity.com>> wrote:
Likewise, FPS does not help with any of my federation use cases.

On Tue, May 31, 2022 at 12:29 PM Nicole Roy <nroy@internet2.edu<mailto:nroy@internet2.edu>> wrote:


On May 30, 2022, at 7:00 AM, Heather Flanagan <hlf@sphericalcowconsulting.com<mailto:hlf@sphericalcowconsulting.com>> wrote:

Hello FedID CG members,

I’d like to bring your attention to a couple of discussions happening over in the PrivacyCG regarding the First Party Sets (FPS) proposal.

  *   Move FPS to different CG/WG (see Issue #88<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fprivacycg%2Ffirst-party-sets%2Fissues%2F88&data=05%7C01%7Ctim.cappalli%40microsoft.com%7Cff98ac5eeea14faa8f9608da43f546e7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637897018009093866%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6fzGfkT6sGnDqqDSGSRYahXtTeldgPVZN7vHHpWMYwU%3D&reserved=0> and 26 May 2022 meeting notes)
  *   Apple WebKit's feedback on the First Party Sets proposal<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.w3.org%2FArchives%2FPublic%2Fpublic-privacycg%2F2022May%2F0006..html&data=05%7C01%7Ctim.cappalli%40microsoft.com%7Cff98ac5eeea14faa8f9608da43f546e7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637897018009093866%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Zvz7W7fCEjjC4gXEYqw43xrUyqq9t9FkNGFqcIwWvlk%3D&reserved=0>
The focus of the PrivacyCG is entirely, as one would expect, on privacy principles whereas the FedID CG focuses on maintaining the functionality of federation in a privacy-focused world. Somewhat different priorities that allow for different directions as ideas are incubated.

My question to the FedID CG is whether anyone thinks that FPS has sufficient utility that it helps solve for their federation use cases? I know some people/orgs have said no, because their orgs have too many domains to fit into a FPS. I also know that the FedCM API, which is our CG’s work product, assumes the existence of FPS and expects to serve as the fallback mechanism if FPS doesn’t apply.

As is somewhat acknowledged toward the end of the email linked above re: WebKit’s take on FPS, FPS is a completely unworkable and inapplicable solution for doing federated single sign-on in the multilateral federation space. From that perspective, FPS does not help with any of my federation use cases.

Best,

Nicole


All feedback is welcome!

Error! Filename not specified.
Heather Flanagan
Spherical Cow Consulting
Error! Filename not specified.<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flinkedin.com%2Fin%2Fhlflanagan%2F&data=05%7C01%7Ctim.cappalli%40microsoft.com%7Cff98ac5eeea14faa8f9608da43f546e7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637897018009093866%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bJws5leI3gFwRSQA4YnBtzDJaWl2eNq8pITnAudYybI%3D&reserved=0>
Error! Filename not specified.<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftwitter.com%2Fsphcow&data=05%7C01%7Ctim.cappalli%40microsoft.com%7Cff98ac5eeea14faa8f9608da43f546e7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637897018009093866%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Ihj95YEWCwqdYkxLdLzPnA%2BN4Cj8h5MoN4ixn%2BZbDQ4%3D&reserved=0>



Error! Filename not specified.

Translator of Geek to Human
Error! Filename not specified.

hlf@sphericalcowconsulting.com<mailto:hlf@sphericalcowconsulting.com>





‌


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


--

Brian May
Principal Engineer
P: (848) 272-1164
This email and any attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender immediately and do not disclose, use, store or copy the information contained herein. This is an email from 51Degrees.mobi Limited, Davidson House, Forbury Square, Reading, RG1 3EU. T: +44 118 328 7152; E: info@51degrees.com<mailto:info@51degrees.com>; 51Degrees.mobi Limited t/as 51Degrees.


This email and any attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender immediately and do not disclose, use, store or copy the information contained herein. This is an email from 51Degrees.mobi Limited, Davidson House, Forbury Square, Reading, RG1 3EU. T: +44 118 328 7152; E: info@51degrees.com; 51Degrees.mobi Limited t/as 51Degrees.