[Openid-specs-ab] Issue #1208: SIOP V2 dynamic iss claim ref: REQUIRED. Issuer. MUST be https://self-issued.me/v2 (openid/connect)

Tobias Looker tobias.looker at mattr.global
Wed Feb 17 01:52:38 UTC 2021


+1 to expanding the iss field beyond https://self-issued.me, at the end of
the day there is still a provider acting as the issuer of the id_token in
SIOP its just that the provider is operating in a more distributed model
(i.e as a PWA or native app on the end-users device) rather than as a
centralized HTTP based authorization server. So being able to identify who
this provider is, rather than some opaque string that points more to how
the provider is operating (e.g https://self-issued.me) is a better all
round solution in my opinion. I think this issue also raises the need
to review the signing process of id_tokens in SIOP.

Thanks,
[image: Mattr website] <https://mattr.global>
*Tobias Looker*
Mattr
+64 (0) 27 378 0461
tobias.looker at mattr.global
[image: Mattr website] <https://mattr.global> [image: Mattr on LinkedIn]
<https://www.linkedin.com/company/mattrglobal> [image: Mattr on Twitter]
<https://twitter.com/mattrglobal> [image: Mattr on Github]
<https://github.com/mattrglobal>
This communication, including any attachments, is confidential. If you are
not the intended recipient, you should not read it - please contact me
immediately, destroy it, and do not copy or use any part of this
communication or disclose anything about it. Thank you. Please note that
this communication does not designate an information system for the
purposes of the Electronic Transactions Act 2002.


On Wed, Feb 17, 2021 at 1:55 PM Adam Lemmon via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> New issue 1208: SIOP V2 dynamic iss claim ref: REQUIRED. Issuer. MUST be
> https://self-issued.me/v2
>
> https://bitbucket.org/openid/connect/issues/1208/siop-v2-dynamic-iss-claim-ref-required
>
> Adam Lemmon:
>
> Hi all,
>
> We have had some good discussions on this during past calls and I wanted
> to formally get this down somewhere to kick off a discussion and aim to
> reach consensus on the use of the `iss` claim in SIOP v2.
>
> We would like to discuss the option of enabling other URIs to be included
> as the `iss` claim and it not be constrained to s[
> elf-issued.me/v2.](http://self-issued.me/v2)
> <http://elf-issued.me/v2.%5D(http://self-issued.me/v2)>
>
> For example being able to specify a URL of a PWA / cloud wallet provider
> as the `iss` , which can prove useful information for an RP that is being
> presented claims from such.  We’d like a model that does not presume a
> specific deployment architecture of a wallet but is inclusive; native, PWA,
> cloud, etc.
>
> Also, we had previously mentioned that the presence of a `sub_jwk` could
> be the signal to the RP that the token is self signed instead of the `iss`
> claim being constrained to s[elf-issued.me/v2](http://self-issued.me/v2)
> <http://elf-issued.me/v2%5D(http://self-issued.me/v2)>, as one option to
> consider.
>
> Look forward to the discussion on this topic, thanks!
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>

-- 
This communication, including any attachments, is confidential. If you are 
not the intended recipient, you should not read it - please contact me 
immediately, destroy it, and do not copy or use any part of this 
communication or disclose anything about it. Thank you. Please note that 
this communication does not designate an information system for the 
purposes of the Electronic Transactions Act 2002.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210217/c4172177/attachment.html>


More information about the Openid-specs-ab mailing list