Re: [Sat] Lock-Evidence artifact type/enumeration

Thank Orie for your input to this discussion.

>There are 2 possible DID "strings", not sure which would be best for your use case

I mean the 1st, i.e. the DiD string, instead of a specific service.
Please refer to https://datatracker.ietf.org/doc/draft-chen-dlt-gateway-identification/ for its rationale and details.

Since it is still in draft, we are open and welcome to other solutions/suggestions.

Cheers
-
Shiping

From: Orie Steele <orie@transmute.industries>
Sent: Wednesday, 8 February 2023 12:57 AM
To: Chen, Shiping (Data61, Eveleigh) <Shiping.Chen@data61.csiro.au>
Cc: sat@ietf.org; Thomas Hardjono <hardjono@mit.edu>
Subject: Re: [Sat] Lock-Evidence artifact type/enumeration

There are 2 possible DID "strings", not sure which would be best for your use case:

## DID

did:example:123

This resolves to cryptographic keys for relationships, such as authentication or assertion, and services for interacting with the DID Subject.

## DID URL

did:example:123/resources/456?query=789#fragment-123

This can dereference resources internal to the DID or external to it... it tends to be more "method specific", so not all methods will support it to the same degree.

It sounds to me like you are discussing a "service" which might be identified like this:

did:web:gateway.example#gateway-42

where there is a service in the DID Document that looks like this:

```
 "service": [{
    "id": "did:web:gateway.example#gateway-42",
    "type": "SATPGateway",
    "serviceEndpoint": "https://gateway.example/api/"
  }]
```

Regards,

OS

On Mon, Feb 6, 2023 at 7:43 PM Chen, Shiping (Data61, Eveleigh) <Shiping.Chen@data61.csiro.au<mailto:Shiping.Chen@data61.csiro.au>> wrote:
> gateway-ID":  "mygateway.com/gw1<http://mygateway.com/gw1>

Its value would/can be a DiD string if being standardized, something like: did:gateway:dwu231dwh, which is resolvable by 1 or multiple DiD repository services.

Cheers
-
Shiping

-----Original Message-----
From: sat <sat-bounces@ietf.org<mailto:sat-bounces@ietf.org>> On Behalf Of Thomas Hardjono
Sent: Tuesday, 7 February 2023 3:01 AM
To: sat@ietf.org<mailto:sat@ietf.org>
Subject: [Sat] Lock-Evidence artifact type/enumeration

Hi All,

I recently received an interesting question about SATP Core and the lock-evidence.

The specific question was about (a) what does the Lock-Evidence artifact (data structure) look like and who will spec it (IETF?), and (b) how to assign some kind of identification to the *type* of the lock (because each network/ledger will have its own data structure).

The lock-evidence structure must have enough information (e.g. block number; record number) to allow the authorized third party (e.g. auditor) to later verify that the Lock-Evidence is true/accurate. This need is independent from the fact the GW1 has signed the message 2.5 (carrying the Lock-Evidence) and is now liable in the case that it makes a mistake or is lying (or was hacked).

The information stated in the Lock-Evidence may also need to be recorded in the Receipt from GW2 to GW1 at the end of the flows in message 3.8.

As reference, here is the link to the current message-flow diagram (v15):

https://bit.ly/3Yw20BT

There are at least 2 places in the message-flow diagram that the type of the lock/ledger needs to be stated.

The first mention is in Stage-0 when gateway GW1 and GW2 are negotiating artifacts and parameters.

The second mention is in message 2.5 in the message-flow diagram, which is also in SATP Core draft in Section 8.3:

   *  lock_evidence_claim REQUIRED.  The lock or escrow evidence (on the
      network behind the client).

   *  lock_claim_format OPTIONAL.  The format of the evidence.

   *  lock_evidence_expiration REQUIRED.  The duration of time of lock
      on the asset (after which the lock is released).

I sketched the following lock-evidence structure (in JSON notation) that could be used in the lock_evidence_claim:

{
       "gateway-ID":  "mygateway.com/gw1<http://mygateway.com/gw1>"
       "lock-evidence type":  "escrow",
       "network-ID":  "7777xa"              [32-byte identifier EIP3220]
       "block number": "775,306bla",
       "block hash": "0000-39ca",
       "escrow holder":  "b7bd-159d"     [hash of address]
       ...
}

Thoughts?