Re: [Blockchain-interop] [EXTERNAL] RE: Scope of Work

[Martin Hargreaves <[e-mail]>]

Hi Thomas,

> >>> I like that, I think that checking for compatible profiles on the
> >>> application and gateway sides is a key validation.
>
> Yes, good idea -- Gateways G1 and G2 need to verify that they are both
> referring to the same asset-profile (independent of the actual instances of
> the asset being transferred, and independent who is the current owner of
> those instances).
>
> The asset-profile could be a signed JSON file that lists factual assertions
> about the virtual asset and links to verify these assertions.  Something like:
>
> -- Profile name/identifier
>
> -- Asset code/number (e.g. "USDT, "WIR", etc.).
>
> -- Asset issuing authority (e.g. "EU ECB", "DTCB NYC", etc.) and jurisdiction.
>
> -- URL to validate the above.
>
> -- Signature of profile author (nb. author could be issuing authority).
>
> -- etc.

I think that works well for digital assets, and should work for most other resource types (e.g. provenance or ESG data). We can certainly test it against the different types of asset group members know about to validate it further.

> >>> Do we also need a naming scheme or identifier format for asset
> >>> profiles / resource profiles?
>
> Yes, I think we do need this.  Any suggestions?

We currently have odapres and odapclient (although we could well change that one), so:

Odapresprofile for a resource profile, and odapauthprofile for an authorization profile? Open to suggestions!

> >>> Looking at the section on negotiation of security protocols and
> >>> parameters, should we also encode this as a set of authorisation
> >>> profiles?
> >>> This would allow easy referenceability for common configurations,
> >>> and allow follow-on work to create new security profiles (e.g. a PQ
> >>> profile).
>
>
> Good idea. Having pre-baked authorization profiles would help speed-up
> transfers.

Great, I'll include this in the next draft.

Best,

Martin

This message is intended solely for the addressee and may contain privileged and confidential information. If you have received this message in error, please send it back to us, and immediately and permanently delete it. Do not use, copy or disclose the information contained in this message or in any attachment. Quant Network does not guarantee that this email has not been intercepted and amended or that it is virus free.