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

Thanks Denis,

I think we could help implementers tremendously by using something you suggested:

did:gateway:tz:tz1aaYoabvj2DQtpHz74Z83fSNjY29asdBfZ

>>>  In such a case we wouldn’t need to implement cascade resolvers, 
>>>  we could just state which resolver we would use to verify the cascade part.

Yes agree. We need to avoid the complexity of (and delays caused by) cascading.

--Thomas

________________________________________
From: Denis Avrilionis [denis@compell.io]
Sent: Wednesday, February 8, 2023 4:30 AM
To: Chen, Shiping (Data61, Eveleigh); Orie Steele; Thomas Hardjono
Cc: sat@ietf.org
Subject: Re: [Sat] Lock-Evidence artifact type/enumeration

Dear Shiping, Orie, Thomas,

Going in the direction of Shiping, one aspect that we may consider is that gateways depend on networks whereas the networks don’t have dependencies on gateways. Therefore we could consider a gateway identity that follows the identification of a given network (see some "network-specific” DID methods in section 14 (registries) here: https://www.w3.org/TR/did-spec-registries/): such a method could look like this:

did:gateway:tz:tz1aaYoabvj2DQtpHz74Z83fSNjY29asdBfZ

the “gateway” is the method, whereas the "tz:tz1aaYoabvj2DQtpHz74Z83fSNjY29asdBfZ" is the method-specific-id of the DID “gateway" method (gateway is kind a of “meta” method)

As defined in https://www.w3.org/TR/did-core/#did-syntax the method-specific-id could be used to contain complete DID methods of “cascade” DIDs. In the example above we should implement the resolution part of the “gateway” part, then define explicitly which resolver we would use to continue verification of the method-specific-id (for example a did “tz” for the tezos registry resolver that would take care of "tz:tz1aaYoabvj2DQtpHz74Z83fSNjY29asdBfZ”). In such a case we wouldn’t need to implement cascade resolvers, we could just state which resolver we would use to verify the cascade part.

Denis

On 8 Feb 2023, at 03:18, Chen, Shiping (Data61, Eveleigh) <Shiping.Chen@data61.csiro.au<mailto:Shiping.Chen@data61.csiro.au>> wrote:

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<mailto:orie@transmute.industries>>
Sent: Wednesday, 8 February 2023 12:57 AM
To: Chen, Shiping (Data61, Eveleigh) <Shiping.Chen@data61.csiro.au<mailto:Shiping.Chen@data61.csiro.au>>
Cc: sat@ietf.org<mailto:sat@ietf.org>; Thomas Hardjono <hardjono@mit.edu<mailto: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?