Hi Karsten,
I'm not sure why I'm on this email chain. Would you kindly remove my email?
Thanks,
Kristen
On Mon, Nov 2, 2020, 12:54 AM Karsten Meyer zu Selhausen <
karsten.meyerzuselhau...@hackmanit.de> wrote:
> Hi all,
>
> Daniel and I published a new version of the "iss" response parameter
This can potentially occur. If JARM is used "iss" becomes redundant. To
me JARM is an "enhanced" iss.
If both are included a sensible client should make sure the iss and the
JARM iss match.
My suggestion is to not require iss when a JARM is present, but in case
both do occur to have the client
Hi Karsten,
The specification mentions JARM. Does this specification require the iss
response parameter even when JARM is used? That is, should an authorization
response look like below?
HTTP/1.1 302 Found
Location: https://client.example.com/cb?response={JWT}={ISSUER}
Or, can the iss response
Thanks Karsten, looks good to me now, no further comments.
Vladimir
On 02/11/2020 09:54, Karsten Meyer zu Selhausen wrote:
>
> Hi all,
>
> Daniel and I published a new version of the "iss" response parameter
> draft to address the feedback from the WG.
>
> Changes in -01:
>
> * Incorporated
Hi all,
Daniel and I published a new version of the "iss" response parameter
draft to address the feedback from the WG.
Changes in -01:
* Incorporated first WG feedback
* Clarifications for use with OIDC
* Added note that clients supporting just one AS are not vulnerable
* Renamed
