[Openid-specs-fastfed] Question about 7.2.4 (Handshake Finalization)

[McAdams, Darin]

>> it might be nice for it to have some error information so the AP knows that the IdP will no longer be attempting.  Or, after 48 hours (or whatever the retry span is), that it was ultimately unsuccessful and what the corresponding error was.

This is reminiscent of another question that arose earlier in the group: Should there be a cancellation flow to abort an in-process registration and clean up data on both sides? While possible, it felt like one of those things that nobody would actually spend time implementing, and they’d just rely on the expiration windows to let things naturally reap. But, I don’t have a strong opinion here. Let us know if anyone else does.  (Vendors could still add their own cancellation buttons, but it would only cleanup their local data. It wouldn’t call across to the other Provider to wipe their bits.)

However, in all transparency, I may change my mind. This is because I need to add more implementation guidance in the spec for how people edit/delete an existing federation relationship that was setup via FastFed. Along the way, I may smack myself in the forehead and realize we need something new in the spec  ; )

From: Brian Rose <brian.rose at sailpoint.com>
Date: Friday, October 18, 2019 at 10:51 AM
To: "McAdams, Darin" <darinm at amazon.com>, Openid-specs-fastfed <openid-specs-fastfed at lists.openid.net>
Cc: Matt Domsch <matt.domsch at sailpoint.com>
Subject: RE: [Openid-specs-fastfed] Question about 7.2.4 (Handshake Finalization)

Yes, that would be great.  Would there be any other information returned in the payload?  Or is it going to be just enough for the AP finalize call to know the issuer and tenant?  At an absolute minimum, “iss” and “sub” are what I would need.

Also, related to the payload, section 7.2.4 states “the Identity Provider MUST invoke this endpoint after successfully processing…”.  Should the finalize endpoint ALWAYS get called, even if there is an error somewhere in the handshake?  If so, it might be nice for it to have some error information so the AP knows that the IdP will no longer be attempting.  Or, after 48 hours (or whatever the retry span is), that it was ultimately unsuccessful and what the corresponding error was.

Thanks,

Brian Rose
Staff Software Engineer
brian.rose at sailpoint.com<mailto:brian.rose at sailpoint.com>
www.sailpoint.com<http://www.sailpoint.com>
From: McAdams, Darin <darinm at amazon.com>
Sent: Wednesday, October 16, 2019 6:19 PM
To: Brian Rose <brian.rose at sailpoint.com>; openid-specs-fastfed at lists.openid.net
Subject: Re: [Openid-specs-fastfed] Question about 7.2.4 (Handshake Finalization)

Good catch. Would it help if a signed JWT came along in this request as well?

From: Openid-specs-fastfed <openid-specs-fastfed-bounces at lists.openid.net<mailto:openid-specs-fastfed-bounces at lists.openid.net>> on behalf of Openid-specs-fastfed <openid-specs-fastfed at lists.openid.net<mailto:openid-specs-fastfed at lists.openid.net>>
Reply-To: Brian Rose <brian.rose at sailpoint.com<mailto:brian.rose at sailpoint.com>>
Date: Thursday, October 10, 2019 at 11:12 AM
To: Openid-specs-fastfed <openid-specs-fastfed at lists.openid.net<mailto:openid-specs-fastfed at lists.openid.net>>
Subject: [Openid-specs-fastfed] Question about 7.2.4 (Handshake Finalization)

Hey all,

In my current POC implementation, I am attempting to set a flag to indicate that the full round trip has been completed in the finalization step.  How does the Application Provider know the provider domain and the tenant id so that it can verify that it has been previously whitelisted and update any associated data that the Application Provider might want to log?  During the registration, the JWT contains all of the necessary information to do the look up.  Also, as a result, is that this endpoint is wide open.

Thanks!
Brian Rose
SailPoint
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fastfed/attachments/20191019/e1f73097/attachment-0001.html>