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=
40compell.io@dmarc.ietf.org> wrote:

> Dear Rafael, Martin,
>
> See comments inline.
>
>
> On 8 Apr 2024, at 16:37, Rafael Belchior <rafael.belchior=
> 40tecnico.ulisboa.pt@dmarc.ietf.org> 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 <internet-drafts@ietf.org> 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
> sat@ietf.org
> https://www.ietf.org/mailman/listinfo/sat
>
>
> --
> sat mailing list
> sat@ietf.org
> https://www.ietf.org/mailman/listinfo/sat
>

-- 

ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>