Re: [OAUTH-WG] [EXT] Re: Fw: New Version Notification for draft-burgin-jenkins-identity-chaining-00.txt

["Dr. Kelley W Burgin" <[e-mail]>]

1. My understanding from Rifaat’s talk this week is that the token returned from token exchange contains the previous token in the “tokens” claim. So, if the process is iterated, the final token would have all previous tokens embedded in it.
2. Our solution only requires the final PR to process top level claims, whereas the embedded token solution requires the final PR to view all nested tokens to retrieve the identity chain of the participants involved.

From: Warren Parad <[e-mail]>
Date: Friday, November 11, 2022 at 10:13 AM
To: "Dr. Kelley W Burgin" <[e-mail]>
Cc: Atul Tulshibagwale <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [EXT] Re: [OAUTH-WG] Fw: New Version Notification for draft-burgin-jenkins-identity-chaining-00.txt

Does it? That's not what I read from the nested jwt draft. If you could point out where it requires either of those to be true I think it would help the draft authors consider your additional use case.

On Fri, Nov 11, 2022 at 11:01 AM Dr. Kelley W Burgin <[e-mail]<mailto:[e-mail]>> wrote:
Thanks Atul.

Warren,

We see the following two benefits of our solution over embedded tokens:

1. Iterated calls (say PR1 needs to access PR2 needs to access … needs to access PR5, all in different trust domains) do not result in a large final token as they would with embedded tokens
2. Our solution puts the burden of adding additional logic in the AS instead of the PRs as embedded tokens would do.

Kelley

From: Atul Tulshibagwale <[e-mail]<mailto:[e-mail]>>
Date: Friday, November 11, 2022 at 9:54 AM
To: Warren Parad <wparad=[e-mail]<mailto:[e-mail]>>, "Dr. Kelley W Burgin" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <mjjenki=[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [EXT] Re: [OAUTH-WG] Fw: New Version Notification for draft-burgin-jenkins-identity-chaining-00.txt

+Dr. Kelley W Burgin<mailto:[e-mail]>
Hi, Kelley would like to respond, so I'm copying him here (he only has the digest of the day)

On Wed, Nov 9, 2022 at 11:08 AM Warren Parad <wparad=[e-mail]<mailto:[e-mail]>> wrote:
I think it would be confusing for implementers to have to figure out the difference between this implementation and https://datatracker.ietf.org/doc/html/draft-yusef-oauth-nested-jwt. This previous one looks to add the exact same information but seems to have a more robust encapsulation mechanism.

On Wed, Nov 9, 2022 at 10:51 AM [e-mail]<mailto:[e-mail]> <mjjenki=[e-mail]<mailto:[e-mail]>> wrote:
Kelley and I have posted a draft to describe what we are trying to accomplish within the Fine-Grained Authorization sub-group.

Mike Jenkins
NSA-CCSS
________________________________
From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, November 8, 2022 7:13 AM
To: Kelley Burgin <[e-mail]<mailto:[e-mail]>>; Michael Jenkins (GOV) <[e-mail]<mailto:[e-mail]>>; Michael Jenkins (GOV) <[e-mail]<mailto:[e-mail]>>
Subject: New Version Notification for draft-burgin-jenkins-identity-chaining-00.txt


A new version of I-D, draft-burgin-jenkins-identity-chaining-00.txt
has been successfully submitted by Mike Jenkins and posted to the
IETF repository.

Name:           draft-burgin-jenkins-identity-chaining
Revision:       00
Title:          OAuth Identity Chaining
Document date:  2022-11-08
Group:          Individual Submission
Pages:          7
URL:            https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-burgin-jenkins-identity-chaining-00.txt&amp;data=05%7C01%7Cmjjenki%40cyber.nsa.gov%7Cda6b9b2940184949b7ad08dac182bfa2%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C638035064561336774%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=bhueo%2BvPkNBZmY5k7jAurvtu29btVjewGiNEsphI33Q%3D&amp;reserved=0
Status:         https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-burgin-jenkins-identity-chaining%2F&amp;data=05%7C01%7Cmjjenki%40cyber.nsa.gov%7Cda6b9b2940184949b7ad08dac182bfa2%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C638035064561336774%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=X%2BimOqs3Vwyw9ckZ64dBJ2fvVotkdT5o10IFZ6zjqhY%3D&amp;reserved=0
Html:           https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-burgin-jenkins-identity-chaining-00.html&amp;data=05%7C01%7Cmjjenki%40cyber.nsa.gov%7Cda6b9b2940184949b7ad08dac182bfa2%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C638035064561336774%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=tHYIgMY6dYUJp0%2FjD9Fyu7dMdWHZSIUMv9YYzdZOI0g%3D&amp;reserved=0
Htmlized:       https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-burgin-jenkins-identity-chaining&amp;data=05%7C01%7Cmjjenki%40cyber.nsa.gov%7Cda6b9b2940184949b7ad08dac182bfa2%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C638035064561336774%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=nUdyXxQm1Q4K%2FKYF6ROhhU1vmCnCBa5RTSM7U6BMks0%3D&amp;reserved=0


Abstract:
   This specification defines a new OAuth claim that allows a proxying
   OAuth client to pass identity information for a different OAuth
   client to an OAuth authorization server during a token request.  The
   authorization server uses this additional identity information when
   populating the "client_id" and "cnf" fields of the returned access
   token instead of the identity information about the proxying client
   requesting the token.




The IETF Secretariat
_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth