Subject: Re: [hrpc] [Secdispatch] Open Ethics Transparency Protocol

From: Eric Rescorla <[email-masked]>
Date: Sat, 12 Mar 2022 15:54:17 -0800

Leading with the [SEC]DISPATCH questions, I don't think we should do
anything here. I would feel differently if there were a significantly
stronger showing of general interest and more evidence that this could
be practically achieved.

I had a fair amount of trouble figuring out what this document was
trying to achieve. My best understanding is that this is intended to
be a machine-readable description of the data processing practices of
a given entity. The current document seems to mix several things:

- A mechanism for retrieving these statements via HTTP
- A schema for the contents of these statements
- A log-based transparency system

The details of all of this are fairly thin and I doubt could be implemented
interoperably. For instance, here's the section on Immutable storage:

   Both the signature integrity hash and the Disclosure SHOULD be stored
   in the log-centric root database and MAY be mirrored by other
   distributed databases for redundancy and safety.

This doesn't seem to define a specific protocol.

My primary question is whether this is a good idea. I have two primary
concerns:

1. Is there real demand for this?
2. Is it going to work.

On the former front, I'd like to hear whether there is a critical mass
of sites which would publish this kind of label. AFAICT nobody has
jumped in to say so on the thread. That seems like a prerequisite for
any IETF activity here.

On the latter piece, the main prior art that I am aware of in
attempting to provide machine-readable descriptions of this sort is
P3P, and I think it's generally agreed that that didn't work out. It's
not clear to me that it's really possible to define a sensible
taxonomy of this kind of information processing.

The description of what goes in the JSON is quite thin and doesn't
seem anywhere near detailed enough to understand the information
processing that a given entity performs.  The label generator linked
to in this draft has a bunch of multiple choice questions, e.g.,

  [ ] Open Source Code
  [ ] Proprietary Source Code

  Code development and reuse

  Please describe choices made for development and for use of existing code
libraries.

First, it's not clear why they are mutually exclusive, as I could use
both. Second, it seems like nearly all the interesting information is
going to be in the freeform portion, which badly undercuts the whole
enterprise.

-Ekr

On Mon, Jan 31, 2022 at 8:13 AM <[email-masked]> wrote:

> Hi everyone,
> Nikita Lukianets from the Open Ethics initiative here.
>
> I've been working on the mechanisms to enable transparency for data
> collection and data processing practices for autonomous systems and
> specifically, those powered by machine learning models. Since 2020 I
> have started to draft a guiding document to reflect ways disclosures
> could be submitted, verified, and exchanged. Eventually, I would like to
> see how this work could result in an open standard.
>
> I've chosen IETF as a home for this work as AI-powered applications are
> becoming ubiquitous. Therefore, we should start looking at them from the
> internet standard and supply chain perspectives.
> There's an emergent need to bring a legally-agnostic and standardized
> way to describe these systems from privacy, security, fairness,
> datasets, and explainability stances.
>
> The idea is simple
> * Following the example of the food (construction, pharma, electrical
> appliance) industry, we need every application to (voluntary) disclose
> the "ingredients", e.g. how data is collected and outputs are produced.
> * We need to have a standard way (protocol) to represent each disclosure
> in human- and machine-readable formats, validate, verify and process
> them.
> * Complex apps will involve chaining the disclosures for the components
> involved.
>
>
> My motivation is to continue the discussion here and get feedback
> allowing us to iterate on the protocol. I'd like to bring this
> discussion to a relevant group or/and welcome the creation of the new
> one, also potentially bringing the conversation to the IETF meeting in
> Vienna.
>
> Below are the links with more info
> Article to bring the context, in plain English
>
> https://lukianets.medium.com/why-algorithmic-transparency-needs-a-protocol-2b6d5098572f
>
> The IETF I-D
>
> https://datatracker.ietf.org/doc/draft-lukianets-open-ethics-transparency-protocol/
>
> GitHub repo
> https://github.com/OpenEthicsAI/OETP
>
> Thanks a lot for your help and thoughts
>
>
> Nikita Lukianets
> Founder, CTO PocketConfidant
> Founder Open Ethics initiative
> Twitter: @nikiluk
> https://fr.linkedin.com/in/nikiluk
> Schedule a 30 min call: https://lukianets.com/meet/
>
> _______________________________________________
> Secdispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch
>

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 13 Mar 2022 21:38:37 -0400

> see how this work could result in an open standard.

I have feelings which are similar to other respondents.  I phrase it
that the IETF is not the correct place for this work because the central
problem is at the application layer (and possibly above that, at the
political layer ... and certainly above that, at the cultural layer):
being transparent presupposes a suitable way to describe "data
collection and data processing practices" in "disclosures".

Once somebody defines a way to represent these disclosures as concrete
document objects, then there may be some protocol issues regarding how
to "submit, verify, and exchange" them.  But that still seems to be more
like the presentation layer, how you associate disclosure documents with
web sites etc. which they describe, which sounds like a W3C specialty.

Dale

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 14 Mar 2022 13:47:25 -0400

Greetings!

I agree with the prior assessment that this is similar to the Software Bill
of Materials work, at least in objectives. That is flexible in terms of
what formats will be acceptable (3) to provide a manifest on software and
many have selected SPDX, then it's digitally signed (code signing). There's
another proposal for this upcoming meeting that will link these for use in
supply chain assurance using Remote Attestation. It might be worth
reviewing that proposal to look for similarities in addition to reviewing
the document from the NTIA on the minimum set of elements for an SBOM.

There's a requirement in the US to any organization that sells to the
federal government to provide an SBOM related to the US executive order
from May 2021.  As such, there's traction on this approach already. With
that said, EKR also pointed out the proposal in this thread is at the
application layer. There may be a possibility for your work to use the
standards being adopted that could accelerate your progress. The next part
would be to determine if that work requires adoption and further
standardization or if the existing formats suffice for what needs to be
interoperable.

At this point, I don't see a time slot being useful, but please respond
with your thoughts if I'm missing something. I hope this is helpful.

Thank you,
Kathleen
co-chair of SecDispatch

-- 

Best regards,
Kathleen

---

From: Nikita Lukianets <[email-masked]>
Date: Mon, 14 Mar 2022 20:18:09 +0200

Hi everyone,
Related to the disclosure formats, we are adopting Model Cards and Data Sheets to a simple JSON file hierarchy which could be parsed and checked and extended using any programming language.

The core idea behind is making machine-readable and human-readable labels interoperable and trusted thanks to a chained validation process. Simple visual example for it exists in creative commons generators though has no machine-readable component.

I apologize for not responding to the comments. Some of you may know that I'm currently in Ukraine and things are, how could I say it... "complex". I don't have reliable internet connection these last days, especially when we have to stay at the bomb shelters.

Indeed, Application layer seems most viable option here and I hope those interested could join the session in art-dispatch, while I'll try to make sure I address previously mentioned comments, especially those related to implementation and examples.

Best,

Nikita Lukianets

On Mar 14, 2022 19:47, Kathleen Moriarty <[email-masked]> wrote:

Greetings!

I agree with the prior assessment that this is similar to the Software Bill of Materials work, at least in objectives. That is flexible in terms of what formats will be acceptable (3) to provide a manifest on software and many have selected SPDX, then it's digitally signed (code signing). There's another proposal for this upcoming meeting that will link these for use in supply chain assurance using Remote Attestation. It might be worth reviewing that proposal to look for similarities in addition to reviewing the document from the NTIA on the minimum set of elements for an SBOM.

There's a requirement in the US to any organization that sells to the federal government to provide an SBOM related to the US executive order from May 2021.  As such, there's traction on this approach already. With that said, EKR also pointed out the proposal in this thread is at the application layer. There may be a possibility for your work to use the standards being adopted that could accelerate your progress. The next part would be to determine if that work requires adoption and further standardization or if the existing formats suffice for what needs to be interoperable.

At this point, I don't see a time slot being useful, but please respond with your thoughts if I'm missing something. I hope this is helpful.

Thank you,

Kathleen

co-chair of SecDispatch

Dale

Secdispatch mailing list

[email-masked]

--

Best regards,

Kathleen