Re: [OAUTH-WG] Transaction tokens draft-ietf-oauth-transaction-tokens-01 - my comments

[Atul Tulshibagwale]

Hi Yaron,
Thank you so much for this feedback. I've created issues
 for many of
the items in your email, and a PR
 for the
minor text fixes you identified.

Atul


On Sun, Mar 24, 2024 at 8:23 PM yaronf.i...@gmail.com 
wrote:

> I had a long flight and I’m still not there yet… But had time to review
> this draft.
>
>
>
> Thanks authors, this is important and useful work. It’s also quite early,
> so I have a long list of comments below.
>
>- Intro: for "workloads", I suggest to add a reference to the WinSE
>Architecture draft.
>- 2.1: "the execution of a call" - I think most people prefer "call
>chain" for this, where "call" only refers to a single hop. (Granted this is
>more of a call tree rather than a call chain, but we use “call chain”
>anyway.)
>- 2.4: additional signatures: I think this is a leftover from a
>previous version of the draft, and as far as I can tell it is not supported
>by this version. Suggest to remove it.
>- 2.5.1: typo, "in an a multi-workload".
>- Figures: what is a "µ-service" and why do we need Greek letters?
>- 4: the terminology section is not a good place for normative
>language, specifically around the "aud" claim.
>- 5.2: I think txn should be OPTIONAL. While it is very useful, there
>may be architectural reasons why transaction ID issuance in an organization
>is independent of transaction tokens.
>- 5.2: "purp" - need a lot more discussion of this claim, also it may
>be OPTIONAL too. Also, why not call it "scope" if that's what it is?
>- 5.2: how is "azd" different from "rctx"? There's a whole section
>about "rctx" and nothing about "azd".
>- 5.2: extensibility: please say explicitly that arbitrary claims may
>be added to the "azd" (and "rctx"?) objects. There is no IANA registry for
>either. Note that having 3 predefined attributes complicates the situation
>a bit - what happens if we want a 4th one? Also mention that any additional
>attributes are local to the trust domain.
>- 5.2: "sub" should be better clarified, this is not your typical
>“sub”. Also, I strongly prefer "sub_id" here (RFC 9493), as the use case I
>have an mind is of the subject as a human. In addition, "as defined by the
>aud trust domain" is confusing, I think you want to say that "sub" is
>relative to the scope of the trust domain.
>- 7.1: the bullets are formatted incorrectly (see HTML version of the
>draft).
>- 7.4.1: maybe say explicitly "MUST NOT change the "sub"', because in
>many use cases this is the most important/sensitive claim.
>- 7.5: unfortunately SPIFFE is only secure for this when used in
>conjunction with MTLS, so please reword the sentence (or wait for WimSE to
>solve this problem).
>- 7.5: SPIFFE - all caps.
>- 8.1: and obviously we need an IANA section to define this HTML
>header.
>- 10.1: *salted* SHA256.
>- 10.1: also, in most cases txn tokens MUST NOT be logged because they
>contain PII (e.g. a subject that's an email address).
>- 11.1: I think there is some confusion here. It is possibly useful to
>define this value (if we want to embed txn tokens within access tokens).
>But the "typ" header is a whole different thing, it needs to be a media
>type. See
>https://datatracker.ietf.org/doc/html/rfc8725#name-use-explicit-typing
>
> Thanks,
>
> Yaron
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth for Browser-Based Apps

[Justin Richer]

I think it does warrant mentioning, because the main assumptions about an spa 
are that everything goes from the browser to the api itself. It might be 
surprising to a user or even a naive developer that every request goes through 
another party as a black box. Even if it's all first party abd deployed 
together, that model should be called out by the draft as an assumption for 
privacy. After all, this section is for considerations - things you should 
think about that might not be obvious.

- Justin

From: Philippe De Ryck 
Sent: Sunday, March 24, 2024 5:40 AM
To: Justin Richer 
Cc: oauth 
Subject: Re: [OAUTH-WG] OAuth for Browser-Based Apps

Hi Justin,

Thank you for your detailed review.

> §9+ this draft should add privacy considerations, particularly for BFF 
> pattern's proxy architecture.e

I wanted to ask for a bit more context on this comment. I understand that 
having a proxy as a separate entity would expose all requests/responses to this 
entity. However, in the context of a BFF, the frontend and the BFF belong 
together (i.e., they are one application deployed as two components). The 
frontend and BFF are deployed and operated by the same party, so I’m not sure 
if this comment effectively applies.

Looking forward to hearing from you.

Philippe
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-zhang-jose-json-fine-grained-access

[jiangcheng]

Thank you very much for your feedback. We will continue to work on it.




-Jiangcheng









At 2024-03-23 18:09:34, "Warren Parad"  wrote:

Some thoughts in no particular order, but mostly I'm with Justin:
The exact data properties of the json probably don't belong in this RFC, but 
rather can be used as an example in the RFC rather than anything normative, as 
the structure defined herein is not sufficient in many cases. Depending exactly 
on how (#2) is done, needs to be more extensible or potentially completely 
ignored since any JSON or even string could be used to achieve #2.
The mechanism of how to use the json to encrypt and decrypt the message feels 
like the only relevant/interesting detail here and it is the main detail left 
out.
I'd recommend cutting the context related to the structure of the request (#1) 
and focus on how it will be used to encrypt/decrypt payloads (#2).


- Warren




On Sat, Mar 23, 2024 at 10:38 AM Justin Richer  wrote:

Thank you for presenting your proposal to the group in Brisbane. 


Reading through the draft, it seemed that there are really two topics in here, 
and I'm wondering how they could be split:


1, a data structure for complex access rights


2, a cryptographic mechanism for selectively encrypting some of those rights to 
protect them from unintentional audiences. 


The data structure used to convey the access rights seems very similar to the 
object structure defined by RAR, RFC9396: 
https://www.rfc-editor.org/rfc/RFC9396 


I was unable to find something in this data structure that is required to 
provide the cryptographic hiding functionality, have I missed something? Or 
would it be possible to apply this to RAR objects? 


Does the key distribution happen or of band of the protocol? In the oauth 
world, would these keys become part of the RS configuration? 


Thank you, 


- Justin 
From: OAuth  on behalf of jiangcheng 

Sent: Tuesday, March 19, 2024 9:42 PM
To:OAuth@ietf.org 
Cc: zhangjl382 ; jill32 
Subject: [OAUTH-WG] draft-zhang-jose-json-fine-grained-access
 


Dear oauth，






  We have a draft and we are looking forward to soliciting comments on it.
https://datatracker.ietf.org/doc/draft-zhang-jose-json-fine-grained-access/


Best regards


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth