Hi George, Great, thanks! I look forward to seeing the clarifications. Appreciate the feedback and I'll leave it to you to create issues.
I think there was only one question for me; I responded below. Dan On Fri, Aug 22, 2025 at 10:11 AM <[email protected]> wrote: > Hi Dan, > > Thank you so much for your thorough and thoughtful review. My sincere > apologies for not responding sooner! > > The editors will be taking this feed back and start work on a PR to update > the spec. No need to create issues unless you want to:) We can pull your > comments to the PR. I’ll drop a few comments inline focusing on the > non-editorial feedback. > > George Fletcher > Identity Standards Architect > Practical Identity LLC > > > > On Aug 14, 2025, at 7:55 PM, Dan Moore <[email protected]> > wrote: > > Hi folks, > > ...snip... > At > https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-7.5.1-2.6.1 > there's a missing 'a': > --- > "MUST NOT issue replacement Txn-token with lifetime exceeding the lifetime > of the originally presented token" > -> > "MUST NOT issue a replacement Txn-Token with lifetime exceeding the > lifetime of the originally presented token" > --- > Also should check for proper casing of Txn-Token throughout the doc. > > At > https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-7.5.2-1 > > The draft says "The scope value in the replacement request, if different > from that in the original Txn-Token, MUST NOT increase the authorization > surface beyond that of the original Txn-Token." > "authorization surface" is kinda vague, but I suppose it leaves some > flexibility up to the Transaction Token Service (to determine that a > different read-only scope is decreasing the surface when a read-write scope > was requested, for example). > > > Yes. I’m not sure how to make this super concrete as authorization within > a trust domain is not currently standardized in any way. If you have a > suggestions for better wording, we would appreciate that! > Maybe an example would help. --- The scope value in the replacement request, if different from that in the original Txn-Token, MUST NOT increase the authorization surface beyond that of the original Txn-Token. Typically, if the scope in the original Txn-Token signified read access to a particular resource, a replacement request shouldn't request write access to that same resource. The specifics of authorization surface decisions are beyond the scope of this document, since scopes within a trust domain are not standardized. --- > > > At > https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-8-1 > I would change: > --- > Note that the standard HTTP Authorization header MUST NOT be used because > that may be used by the workloads to communicate channel authorization. > -> > The Authorization HTTP header MUST NOT be used because that may be used by > the workloads for other purposes. > --- > I have no idea what channel authorization is, but I think it is enough for > implementers to know they MUST NOT use that header. > > ...snip... > > At > https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-11.4-2.2.1 > there is no value for the 'type' > > > Thanks, > Dan > > > > > On Wed, Aug 6, 2025 at 11:04 AM Rifaat Shekh-Yusef < > [email protected]> wrote: > >> All, >> >> As per the discussion in Madrid, this is a *WG Last Call *for the >> *Transaction >> Tokens *document. >> >> https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html >> >> Please, review this document and reply on the mailing list if you have >> any comments or concerns, by August 22nd. >> >> Regards, >> Rifaat & Hannes >> >> _______________________________________________ >> OAuth mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > > > > > > > > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
