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

[Denis Avrilionis <[e-mail]>]

Dear Rafael, Martin,

See comments inline.


> On 8 Apr 2024, at 16:37, Rafael Belchior <rafael.belchior=[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]
> https://www.ietf.org/mailman/listinfo/sat