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 <wpa...@rhosys.ch> Date: Friday, November 11, 2022 at 10:13 AM To: "Dr. Kelley W Burgin" <kbur...@mitre.org> Cc: Atul Tulshibagwale <a...@sgnl.ai>, "mjje...@cyber.nsa.gov" <mjje...@cyber.nsa.gov>, "oauth@ietf.org" <oauth@ietf.org> 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 <kbur...@mitre.org<mailto:kbur...@mitre.org>> 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 <a...@sgnl.ai<mailto:a...@sgnl.ai>> Date: Friday, November 11, 2022 at 9:54 AM To: Warren Parad <wparad=40rhosys...@dmarc.ietf.org<mailto:40rhosys...@dmarc.ietf.org>>, "Dr. Kelley W Burgin" <kbur...@mitre.org<mailto:kbur...@mitre.org>> Cc: "mjje...@cyber.nsa.gov<mailto:mjje...@cyber.nsa.gov>" <mjjenki=40cyber.nsa....@dmarc.ietf.org<mailto:40cyber.nsa....@dmarc.ietf.org>>, "oauth@ietf.org<mailto:oauth@ietf.org>" <oauth@ietf.org<mailto:oauth@ietf.org>> Subject: [EXT] Re: [OAUTH-WG] Fw: New Version Notification for draft-burgin-jenkins-identity-chaining-00.txt +Dr. Kelley W Burgin<mailto:kbur...@mitre.org> 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=40rhosys...@dmarc.ietf.org<mailto:40rhosys...@dmarc.ietf.org>> 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 mjje...@cyber.nsa.gov<mailto:mjje...@cyber.nsa.gov> <mjjenki=40cyber.nsa....@dmarc.ietf.org<mailto:40cyber.nsa....@dmarc.ietf.org>> 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: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> <internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>> Sent: Tuesday, November 8, 2022 7:13 AM To: Kelley Burgin <kelley.bur...@gmail.com<mailto:kelley.bur...@gmail.com>>; Michael Jenkins (GOV) <mjje...@cyber.nsa.gov<mailto:mjje...@cyber.nsa.gov>>; Michael Jenkins (GOV) <mjje...@cyber.nsa.gov<mailto:mjje...@cyber.nsa.gov>> 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&data=05%7C01%7Cmjjenki%40cyber.nsa.gov%7Cda6b9b2940184949b7ad08dac182bfa2%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C638035064561336774%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bhueo%2BvPkNBZmY5k7jAurvtu29btVjewGiNEsphI33Q%3D&reserved=0 Status: https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-burgin-jenkins-identity-chaining%2F&data=05%7C01%7Cmjjenki%40cyber.nsa.gov%7Cda6b9b2940184949b7ad08dac182bfa2%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C638035064561336774%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=X%2BimOqs3Vwyw9ckZ64dBJ2fvVotkdT5o10IFZ6zjqhY%3D&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&data=05%7C01%7Cmjjenki%40cyber.nsa.gov%7Cda6b9b2940184949b7ad08dac182bfa2%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C638035064561336774%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=tHYIgMY6dYUJp0%2FjD9Fyu7dMdWHZSIUMv9YYzdZOI0g%3D&reserved=0 Htmlized: https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-burgin-jenkins-identity-chaining&data=05%7C01%7Cmjjenki%40cyber.nsa.gov%7Cda6b9b2940184949b7ad08dac182bfa2%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C638035064561336774%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=nUdyXxQm1Q4K%2FKYF6ROhhU1vmCnCBa5RTSM7U6BMks0%3D&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 OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
