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

[Wesley Dunnington]

Darin - If this doesn't make it through to the list, could you repost?

 As was mentioned, the JWT that the identity provider sent to the
application provider for the registration request in 7.2.3.1 contains the
IDP domain and the tenant ID of the application provider. The most
straightforward option would be to re-send the initial JWT to the
finalization endpoint. Alternatively the IDP could generate a cut-down JWT
with just the IDP domain and the tenant id.

With regards to returning failure to the finalize URL, I had been of the
opinion that since by that point the entire configuration had been agreed
on by the IDP and Application provider, that the onus would be on the IDP
to fix things and roll forward if it had a problem, calling /finalize when
it was able to do so. If the IDP returned failure at this point it would
seem to me to indicate some sort of serious internal failure. If so I would
imagine the logical course would be to declare the entire federation in
error and restart the entire handshake over.

Wes Dunnington

Wes Dunnington

On Fri, Oct 18, 2019 at 2:05 PM Brian Rose via Openid-specs-fastfed <
openid-specs-fastfed at lists.openid.net> wrote:

> 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
> *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> on behalf of
> Openid-specs-fastfed <openid-specs-fastfed at lists.openid.net>
> *Reply-To: *Brian Rose <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>
> *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
> _______________________________________________
> Openid-specs-fastfed mailing list
> Openid-specs-fastfed at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-fastfed
>


-- 
<https://www.pingidentity.com>[image: Ping Identity]
<https://www.pingidentity.com>
Wesley Dunnington
Field CTO East Region
508-254-5475
wesleydunnington at pingidentity.com

Connect with us: [image: Glassdoor logo]
<https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>
[image:
LinkedIn logo] <https://www.linkedin.com/company/21870> [image: twitter
logo] <https://twitter.com/pingidentity> [image: facebook logo]
<https://www.facebook.com/pingidentitypage> [image: youtube logo]
<https://www.youtube.com/user/PingIdentityTV> [image: Blog logo]
<https://www.pingidentity.com/en/blog.html>
<https://www.google.com/url?q=https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/faqs/en/consumer-attitudes-post-breach-era-3375.pdf?id%3Db6322a80-f285-11e3-ac10-0800200c9a66&source=gmail&ust=1541693608526000&usg=AFQjCNGBl5cPHCUAVKGZ_NnpuFj5PHGSUQ>
<https://www.pingidentity.com/en/events/d/identify-2019.html>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fastfed/attachments/20191018/b74d40ba/attachment-0001.html>