Re: [Sat] I-D Action: draft-ietf-satp-core-04.txt

[Thomas Hardjono <[e-mail]>]

Thanks Orie,

Much appreciate the review.


Best

--thomas



From: sat <[e-mail]> on behalf of Orie Steele <[e-mail]>
Date: Monday, April 8, 2024 at 10:02 AM
To: Denis Avrilionis <denis=[e-mail]>
Cc: Rafael Belchior <rafael.belchior=[e-mail]>, Martin Gfeller <mgf=[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [Sat] I-D Action: draft-ietf-satp-core-04.txt
(as an individual)

If you do end up relaxing this constraint (UUIDv2), please keep in mind that "any UTF-8 string", might cause additional review challenges related to i18n.

You might consider: https://datatracker.ietf.org/doc/html/rfc8264#section-4.2

While I'm pointing out i18n issues:

Section 4.7.7

"""
   This payload is the actual credential of the gateway (token,
   certificate, string, etc.).
"""

Section 14.1.4:

"""
   Specifies a resource held on the underlying network.  This field must
   be meaningful to the network in question but is otherwise an
   arbitrary string.  The underlying object it points to may be a
   network address, data block, transaction ID, alias, etc. or a future
   object type not yet defined.
"""

You might find the treatment of this topic in https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-sfbis-05#section-3.3.8 helpful.

Regards,

OS

On Mon, Apr 8, 2024 at 8:45 AM Denis Avrilionis <denis=[e-mail]<mailto:[e-mail]>> wrote:
Dear Rafael, Martin,

See comments inline.


On 8 Apr 2024, at 16:37, Rafael Belchior <rafael.belchior=[e-mail]<mailto:[e-mail]>> wrote:


Dear Martin,

Thank you a lot for your useful and constructive feedback. I will try my best to address it. Note that, if you wish, you can directly contribute to the draft via a PR in the following repo: https://github.com/ietf-satp/draft-ietf-satp-core

I'll address the comments inline. To the ones I do not respond to, I agree:

A 2024-04-07 23:50, Martin Gfeller escreveu:
Dear Martin, Thomas, and Rafael

The following notes refer to the Draft of SATP Core (https://datatracker.ietf.org/doc/html/draft-ietf-satp-core-04).

Again, my comments may show my limited understanding or my stumbling over certain wordings.

Kind regards, Martin

General

    Is there any reference to the architecture document, which is important to the
    understanding of this document?


You are right - we should refer to it as the theoretical foundation of the SATP core draft. I've added an issue: https://github.com/ietf-satp/draft-ietf-satp-core/issues/12




3. Terminology

    Client application: This is the application employed by a user to interact with a gateway.


        Do we need to say what we want to achieve with the application? Simply interacting
       could mean anything.
        As the introduction mentions only gateways, this is the first time "application" is used.


We should make it clearer that the client application implements the end-user business logic (that requires interoperability) and interacts with a gateway via API1.



    Claim: An assertion made by an Entity [JWT].

        By referencing [JWT], do we prescribe that Claims are encoded as JWTs?
        Either state more explicitly "encoded as JWT", or relax it, as "for example encoded
        as JWT".

I do not have a strong opinion on this. By enforcing JWTs we are facilitating gateway implementations, as they now do not need to check for JWT (or other) support on Stage 0, but it is instead the canonical format for doing claims.



    Claim Type:

        Stipulates that JWT above is just one option. Perhaps always have "X type" before "X";
         i.e., "claim type" before "claim"

    Network:
        Might be worthwhile to define network.


Perhaps we could use ISO WG 307's definition?




4.2 SAT Model

    When do we speak about SAT and when about SATP?

        I think the model is for the protocol, so SATP Model, not SAT Model.

    local gateway

        "local" is understandable, but not actually defined. As the application is defined
         to interact with a gateway, a gateway is always "local" from the perspective of
        the application.

4.7.2 Message Type

    Inconsistent style - drop the  "This is the "

4.7.3 Digital Asset Identifier

    unique identifier (UUIDv2) that uniquely identifies

        unique, more unique, most unique? :-)

:-)

I believe UUIDv2 is too restrictive. I would suggest we mention a more technology-neutral formulation, e.g. that digital asset identifiers should be globally unique and let the implementors decide how the digital asset identifiers could be defined




    application of the beneficiary

        This is the first time the application in NW2 is mentioned in an active role - in
        the document above this point, I understood that while the NW2 and GW2 are involved,
        the application of the beneficiary is not actively involved.

4.7.4 Session ID: (delete the ":")

        Was the Context-Id introduced? Yes, but below. Somewhat circular. Same problem
        noted in Architecture document.

Same comment as above.  UUIDv2 should be one possible mechanism for global unique identification



4.7.5 Transfer-Context ID

        Is the "Sequence Number" part of the Transfer-Context ID, or a possible implementation,
        or something additional?

I believe the sequence number is part of the Transfer-Context ID. Also same comment as above -  UUIDv2 should be one possible mechanism for global unique identification





4.7.8.  Payload Hash

        Is the algo to be used intentionally left open?


I believe that was the rationale. We could support the ones that NIST recommends, in a practical implementation.



4.8  Negotiation of Security Protocols and Parameters

    transfer initiation stage (Stage-0)

        Isn't that Stage-1, according to 4.4?

7-9: Stages

    Do we need to repeat the use of HTTP GET and POST - until the parenthetical remark
    about the TLS nonce for each Stage?

10.2

        The purpose The purpose

    Repeated.

17.2 Informative References

    Wouldn't including references to the SATP Architecture and Use Cases documents be good?

Cheers,

Rafael




On Fri, Apr 5, 2024 at 10:24 AM <[e-mail]<mailto:[e-mail]>> wrote:
Internet-Draft draft-ietf-satp-core-04.txt is now available. It is a work item
of the Secure Asset Transfer Protocol (SATP) WG of the IETF.

   Title:   Secure Asset Transfer Protocol (SATP) Core
   Authors: Martin Hargreaves
            Thomas Hardjono
            Rafael Belchior
   Name:    draft-ietf-satp-core-04.txt
   Pages:   39
   Dates:   2024-04-05

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-satp-core/




--
-- Rafael Belchior

Ph.D. student in Computer Science and Engineering, Blockchain - Técnico Lisboa
https://rafaelapb.github.io/
https://www.linkedin.com/in/rafaelpbelchior/
--
sat mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/sat

--
sat mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/sat


--



ORIE STEELE
Chief Technology Officer
www.transmute.industries

[Image removed by sender.]<https://transmute.industries/>