[Openid-specs-ab] Openid-specs-ab Digest, Vol 390, Issue 11

Phil Hunt phil.hunt at oracle.com
Mon Jul 23 19:47:53 UTC 2018


Mike

I have to agree with Mike S. I have been concerned about the rush into implementer status (in general ) without calls for consensus in the group as to whether something is ready to implement. 

It is particularly upsetting because I cannot vote in the formal votes as a corporate member. 

While federation might be a good, I think and the consensus call may have happened, i still think it critical for contributors and participants to have a say before the members vote. 

Phil

> On Jul 23, 2018, at 12:25 PM, Mike Jones <Michael.Jones at microsoft.com> wrote:
> 
> The point of implementing early drafts of a spec is to learn how well it works and to enable interop testing for the purpose of refining the specification based on what was learned during the interop testing.  It's not expected that early drafts will be placed into production.  We do owe it to implementers, however, to provide IPR protections to them by making specs they’re implementing Implementer’s Drafts.  (As a historical point, OpenID Connect had 5 rounds of interop testing before we decided that it was ready to become final.)
>  
> The concerns I'm hearing, Mike Schwartz, sound more like you're worried that the spec isn't done and not ready to be final than that you're worried that people will learn from implementing early drafts.  You're right that this spec isn't done.  Heck the spec itself makes that clear in the Open Issues section at https://openid.net/specs/openid-connect-federation-1_0-04.html#rfc.appendix.C!
>  
> The idea of "last call" is more about Final Specifications, which won't change after they're final.  We always hold a working group last call before starting the Foundation-wide review of proposed Final Specifications.  Feedback on working drafts is always welcome at any time.
>  
> One thing that's been informally talked about is that it would be great to do some interop work among implementations of the Federation spec at the next IIW which is October 23-25.  I’m sure we’ll learn a lot by having people try their implementations with one another in person.  I hope that many of you will bring running code to IIW!
>  
>                                                        Best wishes,
>                                                        -- Mike
>  
> P.S.  Phil – yes, I still plan to write a “how do working groups work” FAQ.  It’s in my queue, but behind finishing the errata and edits that the working group has discussed to the logout specs and to the Federation spec.
>  
> -----Original Message-----
> From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> On Behalf Of Mike Schwartz via Openid-specs-ab
> Sent: Friday, July 20, 2018 12:53 PM
> To: openid-specs-ab at lists.openid.net
> Subject: Re: [Openid-specs-ab] Openid-specs-ab Digest, Vol 390, Issue 11
>  
> "That said I have complained many times because of issues like this that the WG processes are not published and wg consensus is almost never called.  There is too much rush to implementation without a last call. 
> This is a serious problem the board must resolve."
>  
> Thank you Phil. That's exactly what I was pointing out.
>  
> - Mike
>  
>  
> ------------------------
> Michael Schwartz
> Gluu
> Founder / CEO
> mike at gluu.org
> https://www.linkedin.com/in/nynymike/
>  
> On 2018-07-20 10:19, openid-specs-ab-request at lists.openid.net wrote:
> > Send Openid-specs-ab mailing list submissions to
> >            openid-specs-ab at lists.openid.net
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> >            http://lists.openid.net/mailman/listinfo/openid-specs-ab
> > or, via email, send a message with subject or body 'help' to
> >            openid-specs-ab-request at lists.openid.net
> >
> > You can reach the person managing the list at
> >            openid-specs-ab-owner at lists.openid.net
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Openid-specs-ab digest..."
> >
> >
> > Today's Topics:
> >
> >    1. Re: Please Either ABSTAIN or OBJECT from the Federation Spec
> >       Vote (Phil Hunt)
> >    2. Re: Please Either ABSTAIN or OBJECT from the Federation Spec
> >       Vote (Nick Roy)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Fri, 20 Jul 2018 08:17:26 -0700
> > From: Phil Hunt <phil.hunt at oracle.com>
> > To: Nick Roy <nroy at internet2.edu>
> > Cc: openid-specs-ab at lists.openid.net
> > Subject: Re: [Openid-specs-ab] Please Either ABSTAIN or OBJECT from
> >            the Federation Spec Vote
> > Message-ID: <7E5127BC-E880-4BC9-9F02-DF9600A129A8 at oracle.com>
> > Content-Type: text/plain;         charset=us-ascii
> >
> >
> >
> > Phil
> >
> >> On Jul 20, 2018, at 8:16 AM, Phil Hunt <phil.hunt at oracle.com> wrote:
> >>
> >> I agree with Nick. The correct process (as i sort of understand it)
> >> and discussion was followed.
> >>
> >> That said I have complained many times because of issues like this
> >> that the WG processes are not published and wg consensus is almost
> >> never called.
> >>
> >> There is too much rush to implementation without a last call.
> >>
> >> This is a serious problem the board must resolve.
> >>
> >> Phil
> >>
> >>> On Jul 20, 2018, at 7:34 AM, Nick Roy via Openid-specs-ab
> >>> <openid-specs-ab at lists.openid.net> wrote:
> >>>
> >>> This time to the list...
> >>>
> >>>> On Jul 20, 2018, at 8:30 AM, Nick Roy <nroy at internet2.edu> wrote:
> >>>>
> >>>> Mike, I personally provided feedback to Roland which he
> >>>> incorporated into an updated draft over a year ago. The spec has
> >>>> been available in draft form in github for something like two
> >>>> years.
> >>>>
> >>>> Nick
> >>>>
> >>>> On 7/20/18 8:16 AM, Mike Schwartz via Openid-specs-ab wrote:
> >>>>>> And there's nothing that prevents that, just like there is
> >>>>>> nothing that prevented me from working on HEART if I wanted to.
> >>>>>>
> >>>>>> Nick
> >>>>>
> >>>>> Actually, you're wrong. And I'm pretty active in the OpenID
> >>>>> Connect community... I don't think anyone would say otherwise.
> >>>>>
> >>>>> None of the design decisions on this spec were put to any kind of
> >>>>> vote.
> >>>>> And as I pointed out previously, discussion was limited. It was a
> >>>>> take it or leave it design. Being presented at a conference is not
> >>>>> the same as getting a say in the process.
> >>>>>
> >>>>> It was a closed process, where Jones/Hedburg might or might take
> >>>>> your suggestions, depending on their whim. It has the veneer of
> >>>>> openness, but it's not actually open. It's a one party vote, take
> >>>>> it or leave it.
> >>>>>
> >>>>> I can't start a spec and call it the "Connect AB Alternate
> >>>>> Federation Spec" and have it published here
> >>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_connect_&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=jglkfzh43veJDEsRH8sokGmpsmrh2afbdzoPw7Z-XH0&e=
> >>>>>   So this
> >>>>> spec was given VERY special treatment, placement and promotion.
> >>>>>
> >>>>> Let's not call this an open process when it's not.
> >>>>>
> >>>>> - Mike
> >>>>>
> >>>>>
> >>>>>
> >>>>> ------------------------
> >>>>> Michael Schwartz
> >>>>> Gluu
> >>>>> Founder / CEO
> >>>>> mike at gluu.org
> >>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.
> >>>>> com_in_nynymike_&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eap
> >>>>> I_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt
> >>>>> -b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=hpgFrnPt9eP5DCbWWSkhzDGGgkCLxqsY
> >>>>> B5OxNoFp674&e=
> >>>>>
> >>>>>> On 2018-07-20 06:17, openid-specs-ab-request at lists.openid.net
> >>>>>> wrote:
> >>>>>> Send Openid-specs-ab mailing list submissions to 
> >>>>>> openid-specs-ab at lists.openid.net
> >>>>>>
> >>>>>> To subscribe or unsubscribe via the World Wide Web, visit
> >>>>>> 
> >>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.
> >>>>>> net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwICAg&c=RoP1YumCXCgaW
> >>>>>> HvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI
> >>>>>> 1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=vqMu4
> >>>>>> wpIOPufViYMGvzTtZtsynYxmLnmUHJCL88jWLY&e=
> >>>>>> or, via email, send a message with subject or body 'help' to 
> >>>>>> openid-specs-ab-request at lists.openid.net
> >>>>>>
> >>>>>> You can reach the person managing the list at 
> >>>>>> openid-specs-ab-owner at lists.openid.net
> >>>>>>
> >>>>>> When replying, please edit your Subject line so it is more
> >>>>>> specific than "Re: Contents of Openid-specs-ab digest..."
> >>>>>>
> >>>>>>
> >>>>>> Today's Topics:
> >>>>>>
> >>>>>> 1. Re: Please Either ABSTAIN or OBJECT from the Federation Spec
> >>>>>>    Vote (Nick Roy)
> >>>>>> 2. Issue #1032: rp-initiated logout - proposal for client_id
> >>>>>>    parameter (openid/connect) (Filip Skokan) 3. Re: Issue #1032:
> >>>>>> rp-initiated logout - proposal for client_id
> >>>>>>    parameter (openid/connect) (Vladimir Dzhuvinov) 4. Re: Issue
> >>>>>> #1032: rp-initiated logout - proposal for client_id
> >>>>>>    parameter (openid/connect) (Filip Skokan)
> >>>>>>
> >>>>>>
> >>>>>> -----------------------------------------------------------------
> >>>>>> -----
> >>>>>>
> >>>>>> Message: 1
> >>>>>> Date: Thu, 19 Jul 2018 18:05:45 +0000
> >>>>>> From: Nick Roy <nroy at internet2.edu>
> >>>>>> To: "openid-specs-ab at lists.openid.net"
> >>>>>>  <openid-specs-ab at lists.openid.net>
> >>>>>> Subject: Re: [Openid-specs-ab] Please Either ABSTAIN or OBJECT
> >>>>>> from  the Federation Spec Vote
> >>>>>> Message-ID:
> >>>>>> 
> >>>>>> <CY4PR08MB35449C06D30AE97F5188DDFA83520 at CY4PR08MB3544.namprd08.pr
> >>>>>> od.outlook.com>
> >>>>>>
> >>>>>> Content-Type: text/plain; charset="us-ascii"
> >>>>>>
> >>>>>> And there's nothing that prevents that, just like there is
> >>>>>> nothing that prevented me from working on HEART if I wanted to.
> >>>>>>
> >>>>>> Nick
> >>>>>>
> >>>>>>> On 7/19/18 10:43 AM, Mike Schwartz via Openid-specs-ab wrote:
> >>>>>>> Nick,
> >>>>>>>
> >>>>>>> I thought you had a good idea to move federation to its own WG.
> >>>>>>>
> >>>>>>> So of course, I'm all for OpenID federations. And I'm also
> >>>>>>> really interested in this proposed design. And I appreciate the
> >>>>>>> work done by the current editors. It might be the best way. But
> >>>>>>> I was never given a choice of A or B. I was just given a choice
> >>>>>>> to approve A.
> >>>>>>>
> >>>>>>> I think the community should get a say in this design of this
> >>>>>>> spec.
> >>>>>>>
> >>>>>>> - Mike
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> it sounds like you aren't interested in working in an R&E
> >>>>>>>> working group.
> >>>>>>>> My understanding is that this WG will pursue R&E use cases for
> >>>>>>>> this profile. Since R&E is one of the largest users of
> >>>>>>>> multilateral SAML federation, I think exploring use of the OIDC
> >>>>>>>> Federation work in that space is a great next step.
> >>>>>>>>
> >>>>>>>> Nick
> >>>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Openid-specs-ab mailing list
> >>>>>>> Openid-specs-ab at lists.openid.net
> >>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid
> >>>>>>> .net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwICAg&c=RoP1YumCXCg
> >>>>>>> aWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqP
> >>>>>>> kAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=v
> >>>>>>> qMu4wpIOPufViYMGvzTtZtsynYxmLnmUHJCL88jWLY&e=
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> ------------------------------
> >>>>>>
> >>>>>> Message: 2
> >>>>>> Date: Fri, 20 Jul 2018 08:10:50 +0000 (UTC)
> >>>>>> From: "Filip Skokan" <issues-reply at bitbucket.org>
> >>>>>> To: openid-specs-ab at lists.openid.net
> >>>>>> Subject: [Openid-specs-ab] Issue #1032: rp-initiated logout -
> >>>>>> proposal  for client_id parameter (openid/connect)
> >>>>>> Message-ID:
> >>>>>>  <20180720081050.39616.17365 at celery-worker-105.ash1.bb-inf.net>
> >>>>>> Content-Type: text/plain; charset="utf-8"
> >>>>>>
> >>>>>> New issue 1032: rp-initiated logout - proposal for client_id
> >>>>>> parameter
> >>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bitbucket.or
> >>>>>> g_openid_connect_issues_1032_rp-2Dinitiated-2Dlogout-2Dproposal-2
> >>>>>> Dfor-2Dclient-5Fid&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65
> >>>>>> eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHB
> >>>>>> ZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=XPovg09GXpcxWGyelD8zKNCUzJP
> >>>>>> 71dmPh3bNGNK7k5w&e=
> >>>>>>
> >>>>>> Filip Skokan:
> >>>>>>
> >>>>>> I'd like to request that a parameter (optional or required?)
> >>>>>> client_id is defined for rp-initiated logout request.
> >>>>>>
> >>>>>> rationale:
> >>>>>>
> >>>>>> Currently the id_token_hint is the only way of identifying the
> >>>>>> client that's making the request. In scenarios where a client
> >>>>>> does not yet have an id_token but makes a request to authenticate
> >>>>>> which fails (e.g.
> >>>>>> due to being requested with essential sub claim through claims)
> >>>>>> the next step will be to trigger an rp initiated logout with a
> >>>>>> registered post_logout_redirect_uri but without an id_token_hint.
> >>>>>> This can be problematic for OP deployments with a high number of
> >>>>>> clients as it is not efficient or sometimes even not possible to
> >>>>>> iterate over all of them to see if this post_logout_redirect_uri
> >>>>>> is whitelisted or not.
> >>>>>> Hence the client_id parameter to make this lookup possible and
> >>>>>> efficient.
> >>>>>>
> >>>>>> Further processing may be defined such as if both client_id and
> >>>>>> id_token_hint are provided the audience of the id_token_hint must
> >>>>>> include the client_id etc.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> ------------------------------
> >>>>>>
> >>>>>> Message: 3
> >>>>>> Date: Fri, 20 Jul 2018 14:01:29 +0300
> >>>>>> From: Vladimir Dzhuvinov <vladimir at connect2id.com>
> >>>>>> To: openid-specs-ab at lists.openid.net
> >>>>>> Subject: Re: [Openid-specs-ab] Issue #1032: rp-initiated logout - 
> >>>>>> proposal for client_id parameter (openid/connect)
> >>>>>> Message-ID: <14898981-27c9-8a85-91c8-77c93a931278 at connect2id.com>
> >>>>>> Content-Type: text/plain; charset="utf-8"
> >>>>>>
> >>>>>> Hi Filip,
> >>>>>>
> >>>>>> My concern is that relying on the client_id opens up post logout
> >>>>>> redirection to potential misuse.
> >>>>>>
> >>>>>> IMO the OP shouldn't be picking any redirections if cannot be
> >>>>>> sure, to a satisfactory degree, that it's the legitimate RP
> >>>>>> making the call.
> >>>>>>
> >>>>>> The ID token isn't really a substitute for proper RP
> >>>>>> authentication, but it's some way towards that.
> >>>>>>
> >>>>>> A JWS request might help here, but it's probably too much to ask
> >>>>>> from RPs.
> >>>>>>
> >>>>>> Vladimir
> >>>>>>
> >>>>>>
> >>>>>>> On 20/07/18 11:10, Filip Skokan via Openid-specs-ab wrote:
> >>>>>>> New issue 1032: rp-initiated logout - proposal for client_id
> >>>>>>> parameter
> >>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bitbucket.o
> >>>>>>> rg_openid_connect_issues_1032_rp-2Dinitiated-2Dlogout-2Dproposal
> >>>>>>> -2Dfor-2Dclient-5Fid&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMU
> >>>>>>> B65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYR
> >>>>>>> DsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=XPovg09GXpcxWGyelD8zKN
> >>>>>>> CUzJP71dmPh3bNGNK7k5w&e=
> >>>>>>>
> >>>>>>> Filip Skokan:
> >>>>>>>
> >>>>>>> I'd like to request that a parameter (optional or required?)
> >>>>>>> client_id is defined for rp-initiated logout request.
> >>>>>>>
> >>>>>>> rationale:
> >>>>>>>
> >>>>>>> Currently the id_token_hint is the only way of identifying the
> >>>>>>> client that's making the request. In scenarios where a client
> >>>>>>> does not yet have an id_token but makes a request to
> >>>>>>> authenticate which fails (e.g.
> >>>>>>> due to being requested with essential sub claim through claims)
> >>>>>>> the next step will be to trigger an rp initiated logout with a
> >>>>>>> registered post_logout_redirect_uri but without an
> >>>>>>> id_token_hint. This can be problematic for OP deployments with a
> >>>>>>> high number of clients as it is not efficient or sometimes even
> >>>>>>> not possible to iterate over all of them to see if this
> >>>>>>> post_logout_redirect_uri is whitelisted or not.
> >>>>>>> Hence the client_id parameter to make this lookup possible and
> >>>>>>> efficient.
> >>>>>>>
> >>>>>>> Further processing may be defined such as if both client_id and
> >>>>>>> id_token_hint are provided the audience of the id_token_hint
> >>>>>>> must include the client_id etc.
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> -------------- next part -------------- A non-text attachment was
> >>>>>> scrubbed...
> >>>>>> Name: smime.p7s
> >>>>>> Type: application/pkcs7-signature
> >>>>>> Size: 4002 bytes
> >>>>>> Desc: S/MIME Cryptographic Signature
> >>>>>> URL:
> >>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid
> >>>>>> .net_pipermail_openid-2Dspecs-2Dab_attachments_20180720_00f40e94_
> >>>>>> attachment-2D0001.p7s&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMU
> >>>>>> B65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRD
> >>>>>> sHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=eTHo7f8tNiakUT3d8PkF8AQg
> >>>>>> Sq44lpjr4_2Y7S8skp4&e=>
> >>>>>>
> >>>>>> ------------------------------
> >>>>>>
> >>>>>> Message: 4
> >>>>>> Date: Fri, 20 Jul 2018 13:16:52 +0200
> >>>>>> From: Filip Skokan <panva.ip at gmail.com>
> >>>>>> To: Vladimir Dzhuvinov <vladimir at connect2id.com>
> >>>>>> Cc: "openid-specs-ab at lists.openid.net Ab"
> >>>>>>  <openid-specs-ab at lists.openid.net>
> >>>>>> Subject: Re: [Openid-specs-ab] Issue #1032: rp-initiated logout - 
> >>>>>> proposal for client_id parameter (openid/connect)
> >>>>>> Message-ID:
> >>>>>> 
> >>>>>> <CALAqi_8w2uvCd9R39YQpL-QxT7srCTvgpQvqkGXnrfo80owEFw at mail.gmail.c
> >>>>>> om>
> >>>>>> Content-Type: text/plain; charset="utf-8"
> >>>>>>
> >>>>>> Hello Vladimir,
> >>>>>>
> >>>>>> The OP is advised to render a prompt for the end-user in those
> >>>>>> cases where post_logout_redirect_uri is not provided. And there's
> >>>>>> no mention of ignoring the post_logout_redirect_uri param if
> >>>>>> id_token_hint is missing.
> >>>>>>
> >>>>>> Currently:
> >>>>>>
> >>>>>>> post_logout_redirect_uri
> >>>>>>> OPTIONAL. URL to which the RP is requesting that the End-User's
> >>>>>>> User Agent be redirected after a logout has been performed. The
> >>>>>>> value MUST have been previously registered with the OP, either
> >>>>>>> using the post_logout_redirect_uris Registration parameter or
> >>>>>>> via another mechanism.
> >>>>>>> If supplied, the OP SHOULD honor this request following the
> >>>>>>> logout.
> >>>>>>
> >>>>>>
> >>>>>> No mention of ignoring the value if id_token_hint is not provided.
> >>>>>>
> >>>>>> and under security considerations, the advise to prompt.
> >>>>>>
> >>>>>> The id_token_hint parameter to a logout request can be used to
> >>>>>> determine
> >>>>>>> which RP initiated the logout request. Logout requests without a
> >>>>>>> valid id_token_hint value are a potential means of denial of
> >>>>>>> service; therefore, OPs may want to require explicit user
> >>>>>>> confirmation before acting upon them.
> >>>>>>
> >>>>>>
> >>>>>> Supplying a client_id does not change a potential extra OP policy
> >>>>>> that id_token_hint must be provided if it choses to do so, it
> >>>>>> simply makes post_logout_redirect_uri lookup possible in cases
> >>>>>> where loading all uris or clients into memory is not possible/is
> >>>>>> inefficient or can't query for all valid uris for the same
> >>>>>> reasons.
> >>>>>>
> >>>>>> Best,
> >>>>>> *Filip*
> >>>>>>
> >>>>>>
> >>>>>> On Fri, Jul 20, 2018 at 1:01 PM Vladimir Dzhuvinov via
> >>>>>> Openid-specs-ab < openid-specs-ab at lists.openid.net> wrote:
> >>>>>>
> >>>>>>> Hi Filip,
> >>>>>>>
> >>>>>>> My concern is that relying on the client_id opens up post logout
> >>>>>>> redirection to potential misuse.
> >>>>>>>
> >>>>>>> IMO the OP shouldn't be picking any redirections if cannot be
> >>>>>>> sure, to a satisfactory degree, that it's the legitimate RP
> >>>>>>> making the call.
> >>>>>>>
> >>>>>>> The ID token isn't really a substitute for proper RP
> >>>>>>> authentication, but it's some way towards that.
> >>>>>>>
> >>>>>>> A JWS request might help here, but it's probably too much to ask
> >>>>>>> from RPs.
> >>>>>>>
> >>>>>>> Vladimir
> >>>>>>>
> >>>>>>>
> >>>>>>>> On 20/07/18 11:10, Filip Skokan via Openid-specs-ab wrote:
> >>>>>>>> New issue 1032: rp-initiated logout - proposal for client_id
> >>>>>>>> parameter
> >>>>>>>>
> >>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bitbucket.o
> >>>>>>> rg_openid_connect_issues_1032_rp-2Dinitiated-2Dlogout-2Dproposal
> >>>>>>> -2Dfor-2Dclient-5Fid&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMU
> >>>>>>> B65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYR
> >>>>>>> DsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=XPovg09GXpcxWGyelD8zKN
> >>>>>>> CUzJP71dmPh3bNGNK7k5w&e=
> >>>>>>>>
> >>>>>>>> Filip Skokan:
> >>>>>>>>
> >>>>>>>> I'd like to request that a parameter (optional or required?)
> >>>>>>>> client_id
> >>>>>>> is defined for rp-initiated logout request.
> >>>>>>>>
> >>>>>>>> rationale:
> >>>>>>>>
> >>>>>>>> Currently the id_token_hint is the only way of identifying the
> >>>>>>>> client
> >>>>>>> that's making the request. In scenarios where a client does not
> >>>>>>> yet have an id_token but makes a request to authenticate which
> >>>>>>> fails (e.g.
> >>>>>>> due to
> >>>>>>> being
> >>>>>>> requested with essential sub claim through claims) the next step
> >>>>>>> will be to trigger an rp initiated logout with a registered
> >>>>>>> post_logout_redirect_uri but without an id_token_hint. This can
> >>>>>>> be problematic for OP deployments with a high number of clients
> >>>>>>> as it is not efficient or sometimes even not possible to iterate
> >>>>>>> over all of them to see if this post_logout_redirect_uri is
> >>>>>>> whitelisted or not. Hence the client_id parameter to make this
> >>>>>>> lookup possible and efficient.
> >>>>>>>>
> >>>>>>>> Further processing may be defined such as if both client_id and
> >>>>>>> id_token_hint are provided the audience of the id_token_hint
> >>>>>>> must include the client_id etc.
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Openid-specs-ab mailing list
> >>>>>>> Openid-specs-ab at lists.openid.net
> >>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid
> >>>>>>> .net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwICAg&c=RoP1YumCXCg
> >>>>>>> aWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqP
> >>>>>>> kAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=v
> >>>>>>> qMu4wpIOPufViYMGvzTtZtsynYxmLnmUHJCL88jWLY&e=
> >>>>>>>
> >>>>>> -------------- next part -------------- An HTML attachment was
> >>>>>> scrubbed...
> >>>>>> URL:
> >>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid
> >>>>>> .net_pipermail_openid-2Dspecs-2Dab_attachments_20180720_43cba25d_
> >>>>>> attachment.html&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eap
> >>>>>> I_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhY
> >>>>>> t-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=KmCCQjnkztIL-CzFEhohJrsvdGwCZt
> >>>>>> WRDGDfwFTOOTs&e=>
> >>>>>>
> >>>>>> ------------------------------
> >>>>>>
> >>>>>> Subject: Digest Footer
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Openid-specs-ab mailing list
> >>>>>> Openid-specs-ab at lists.openid.net
> >>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.
> >>>>>> net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwICAg&c=RoP1YumCXCgaW
> >>>>>> HvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI
> >>>>>> 1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=vqMu4
> >>>>>> wpIOPufViYMGvzTtZtsynYxmLnmUHJCL88jWLY&e=
> >>>>>>
> >>>>>>
> >>>>>> ------------------------------
> >>>>>>
> >>>>>> End of Openid-specs-ab Digest, Vol 390, Issue 9
> >>>>>> ***********************************************
> >>>>> _______________________________________________
> >>>>> Openid-specs-ab mailing list
> >>>>> Openid-specs-ab at lists.openid.net
> >>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.n
> >>>>> et_mailman_listinfo_openid-2Dspecs-2Dab&d=DwICAg&c=RoP1YumCXCgaWHv
> >>>>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aL
> >>>>> cLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=vqMu4wpIO
> >>>>> PufViYMGvzTtZtsynYxmLnmUHJCL88jWLY&e=
> >>>>>
> >>>>
> >>> _______________________________________________
> >>> Openid-specs-ab mailing list
> >>> Openid-specs-ab at lists.openid.net
> >>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net
> >>> _mailman_listinfo_openid-2Dspecs-2Dab&d=DwICAg&c=RoP1YumCXCgaWHvlZYR
> >>> 8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZ
> >>> NA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=vqMu4wpIOPufViYMG
> >>> vzTtZtsynYxmLnmUHJCL88jWLY&e=
> >
> >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Fri, 20 Jul 2018 15:19:28 +0000
> > From: Nick Roy <nroy at internet2.edu>
> > To: Phil Hunt <phil.hunt at oracle.com>
> > Cc: "openid-specs-ab at lists.openid.net"
> >            <openid-specs-ab at lists.openid.net>
> > Subject: Re: [Openid-specs-ab] Please Either ABSTAIN or OBJECT from
> >            the Federation Spec Vote
> > Message-ID:
> >           
> > <CY4PR08MB3544B2C3C1D544E44322D7E583510 at CY4PR08MB3544.namprd08.prod.ou
> > tlook.com>
> >
> > Content-Type: text/plain; charset="us-ascii"
> >
> > As shown by both my and Phil's accidental replies off-list, there also
> > seems to be a list configuration issue which sets the reply-to address
> > as the address of the poster, rather than the address of the list.
> >
> > Nick
> >
> > On 7/20/18 9:17 AM, Phil Hunt wrote:
> >>
> >>
> >> Phil
> >>
> >>> On Jul 20, 2018, at 8:16 AM, Phil Hunt <phil.hunt at oracle.com> wrote:
> >>>
> >>> I agree with Nick. The correct process (as i sort of understand it)
> >>> and discussion was followed.
> >>>
> >>> That said I have complained many times because of issues like this
> >>> that the WG processes are not published and wg consensus is almost
> >>> never called.
> >>>
> >>> There is too much rush to implementation without a last call.
> >>>
> >>> This is a serious problem the board must resolve.
> >>>
> >>> Phil
> >>>
> >>>> On Jul 20, 2018, at 7:34 AM, Nick Roy via Openid-specs-ab
> >>>> <openid-specs-ab at lists.openid.net> wrote:
> >>>>
> >>>> This time to the list...
> >>>>
> >>>>> On Jul 20, 2018, at 8:30 AM, Nick Roy <nroy at internet2.edu> wrote:
> >>>>>
> >>>>> Mike, I personally provided feedback to Roland which he
> >>>>> incorporated into an updated draft over a year ago. The spec has
> >>>>> been available in draft form in github for something like two
> >>>>> years.
> >>>>>
> >>>>> Nick
> >>>>>
> >>>>> On 7/20/18 8:16 AM, Mike Schwartz via Openid-specs-ab wrote:
> >>>>>>> And there's nothing that prevents that, just like there is
> >>>>>>> nothing that prevented me from working on HEART if I wanted to.
> >>>>>>>
> >>>>>>> Nick
> >>>>>>
> >>>>>> Actually, you're wrong. And I'm pretty active in the OpenID
> >>>>>> Connect community... I don't think anyone would say otherwise.
> >>>>>>
> >>>>>> None of the design decisions on this spec were put to any kind of
> >>>>>> vote.
> >>>>>> And as I pointed out previously, discussion was limited. It was a
> >>>>>> take it or leave it design. Being presented at a conference is
> >>>>>> not the same as getting a say in the process.
> >>>>>>
> >>>>>> It was a closed process, where Jones/Hedburg might or might take
> >>>>>> your suggestions, depending on their whim. It has the veneer of
> >>>>>> openness, but it's not actually open. It's a one party vote, take
> >>>>>> it or leave it.
> >>>>>>
> >>>>>> I can't start a spec and call it the "Connect AB Alternate
> >>>>>> Federation Spec" and have it published here
> >>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_connect_&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=jglkfzh43veJDEsRH8sokGmpsmrh2afbdzoPw7Z-XH0&e=
> >>>>>>   So this
> >>>>>> spec was given VERY special treatment, placement and promotion.
> >>>>>>
> >>>>>> Let's not call this an open process when it's not.
> >>>>>>
> >>>>>> - Mike
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> ------------------------
> >>>>>> Michael Schwartz
> >>>>>> Gluu
> >>>>>> Founder / CEO
> >>>>>> mike at gluu.org
> >>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin
> >>>>>> .com_in_nynymike_&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65e
> >>>>>> apI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZ
> >>>>>> hYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=hpgFrnPt9eP5DCbWWSkhzDGGgkCL
> >>>>>> xqsYB5OxNoFp674&e=
> >>>>>>
> >>>>>>> On 2018-07-20 06:17, openid-specs-ab-request at lists.openid.net
> >>>>>>> wrote:
> >>>>>>> Send Openid-specs-ab mailing list submissions to 
> >>>>>>> openid-specs-ab at lists.openid.net
> >>>>>>>
> >>>>>>> To subscribe or unsubscribe via the World Wide Web, visit
> >>>>>>> 
> >>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid
> >>>>>>> .net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwICAg&c=RoP1YumCXCg
> >>>>>>> aWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqP
> >>>>>>> kAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=v
> >>>>>>> qMu4wpIOPufViYMGvzTtZtsynYxmLnmUHJCL88jWLY&e=
> >>>>>>> or, via email, send a message with subject or body 'help' to 
> >>>>>>> openid-specs-ab-request at lists.openid.net
> >>>>>>>
> >>>>>>> You can reach the person managing the list at 
> >>>>>>> openid-specs-ab-owner at lists.openid.net
> >>>>>>>
> >>>>>>> When replying, please edit your Subject line so it is more
> >>>>>>> specific than "Re: Contents of Openid-specs-ab digest..."
> >>>>>>>
> >>>>>>>
> >>>>>>> Today's Topics:
> >>>>>>>
> >>>>>>> 1. Re: Please Either ABSTAIN or OBJECT from the Federation Spec
> >>>>>>>    Vote (Nick Roy)
> >>>>>>> 2. Issue #1032: rp-initiated logout - proposal for client_id
> >>>>>>>    parameter (openid/connect) (Filip Skokan) 3. Re: Issue #1032:
> >>>>>>> rp-initiated logout - proposal for client_id
> >>>>>>>    parameter (openid/connect) (Vladimir Dzhuvinov) 4. Re: Issue
> >>>>>>> #1032: rp-initiated logout - proposal for client_id
> >>>>>>>    parameter (openid/connect) (Filip Skokan)
> >>>>>>>
> >>>>>>>
> >>>>>>> ----------------------------------------------------------------
> >>>>>>> ------
> >>>>>>>
> >>>>>>> Message: 1
> >>>>>>> Date: Thu, 19 Jul 2018 18:05:45 +0000
> >>>>>>> From: Nick Roy <nroy at internet2.edu>
> >>>>>>> To: "openid-specs-ab at lists.openid.net"
> >>>>>>>  <openid-specs-ab at lists.openid.net>
> >>>>>>> Subject: Re: [Openid-specs-ab] Please Either ABSTAIN or OBJECT
> >>>>>>> from  the Federation Spec Vote
> >>>>>>> Message-ID:
> >>>>>>> 
> >>>>>>> <CY4PR08MB35449C06D30AE97F5188DDFA83520 at CY4PR08MB3544.namprd08.p
> >>>>>>> rod.outlook.com>
> >>>>>>>
> >>>>>>> Content-Type: text/plain; charset="us-ascii"
> >>>>>>>
> >>>>>>> And there's nothing that prevents that, just like there is
> >>>>>>> nothing that prevented me from working on HEART if I wanted to.
> >>>>>>>
> >>>>>>> Nick
> >>>>>>>
> >>>>>>>> On 7/19/18 10:43 AM, Mike Schwartz via Openid-specs-ab wrote:
> >>>>>>>> Nick,
> >>>>>>>>
> >>>>>>>> I thought you had a good idea to move federation to its own WG.
> >>>>>>>>
> >>>>>>>> So of course, I'm all for OpenID federations. And I'm also
> >>>>>>>> really interested in this proposed design. And I appreciate the
> >>>>>>>> work done by the current editors. It might be the best way. But
> >>>>>>>> I was never given a choice of A or B. I was just given a choice
> >>>>>>>> to approve A.
> >>>>>>>>
> >>>>>>>> I think the community should get a say in this design of this
> >>>>>>>> spec.
> >>>>>>>>
> >>>>>>>> - Mike
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> it sounds like you aren't interested in working in an R&E
> >>>>>>>>> working group.
> >>>>>>>>> My understanding is that this WG will pursue R&E use cases for
> >>>>>>>>> this profile. Since R&E is one of the largest users of
> >>>>>>>>> multilateral SAML federation, I think exploring use of the
> >>>>>>>>> OIDC Federation work in that space is a great next step.
> >>>>>>>>>
> >>>>>>>>> Nick
> >>>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> Openid-specs-ab mailing list
> >>>>>>>> Openid-specs-ab at lists.openid.net
> >>>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openi
> >>>>>>>> d.net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwICAg&c=RoP1YumCX
> >>>>>>>> CgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpu
> >>>>>>>> YqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw
> >>>>>>>> &s=vqMu4wpIOPufViYMGvzTtZtsynYxmLnmUHJCL88jWLY&e=
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> ------------------------------
> >>>>>>>
> >>>>>>> Message: 2
> >>>>>>> Date: Fri, 20 Jul 2018 08:10:50 +0000 (UTC)
> >>>>>>> From: "Filip Skokan" <issues-reply at bitbucket.org>
> >>>>>>> To: openid-specs-ab at lists.openid.net
> >>>>>>> Subject: [Openid-specs-ab] Issue #1032: rp-initiated logout -
> >>>>>>> proposal  for client_id parameter (openid/connect)
> >>>>>>> Message-ID:
> >>>>>>>  <20180720081050.39616.17365 at celery-worker-105.ash1.bb-inf.net>
> >>>>>>> Content-Type: text/plain; charset="utf-8"
> >>>>>>>
> >>>>>>> New issue 1032: rp-initiated logout - proposal for client_id
> >>>>>>> parameter
> >>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bitbucket.o
> >>>>>>> rg_openid_connect_issues_1032_rp-2Dinitiated-2Dlogout-2Dproposal
> >>>>>>> -2Dfor-2Dclient-5Fid&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMU
> >>>>>>> B65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYR
> >>>>>>> DsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=XPovg09GXpcxWGyelD8zKN
> >>>>>>> CUzJP71dmPh3bNGNK7k5w&e=
> >>>>>>>
> >>>>>>> Filip Skokan:
> >>>>>>>
> >>>>>>> I'd like to request that a parameter (optional or required?)
> >>>>>>> client_id is defined for rp-initiated logout request.
> >>>>>>>
> >>>>>>> rationale:
> >>>>>>>
> >>>>>>> Currently the id_token_hint is the only way of identifying the
> >>>>>>> client that's making the request. In scenarios where a client
> >>>>>>> does not yet have an id_token but makes a request to
> >>>>>>> authenticate which fails (e.g.
> >>>>>>> due to being requested with essential sub claim through claims)
> >>>>>>> the next step will be to trigger an rp initiated logout with a
> >>>>>>> registered post_logout_redirect_uri but without an
> >>>>>>> id_token_hint. This can be problematic for OP deployments with a
> >>>>>>> high number of clients as it is not efficient or sometimes even
> >>>>>>> not possible to iterate over all of them to see if this
> >>>>>>> post_logout_redirect_uri is whitelisted or not.
> >>>>>>> Hence the client_id parameter to make this lookup possible and
> >>>>>>> efficient.
> >>>>>>>
> >>>>>>> Further processing may be defined such as if both client_id and
> >>>>>>> id_token_hint are provided the audience of the id_token_hint
> >>>>>>> must include the client_id etc.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> ------------------------------
> >>>>>>>
> >>>>>>> Message: 3
> >>>>>>> Date: Fri, 20 Jul 2018 14:01:29 +0300
> >>>>>>> From: Vladimir Dzhuvinov <vladimir at connect2id.com>
> >>>>>>> To: openid-specs-ab at lists.openid.net
> >>>>>>> Subject: Re: [Openid-specs-ab] Issue #1032: rp-initiated logout
> >>>>>>> -  proposal for client_id parameter (openid/connect)
> >>>>>>> Message-ID:
> >>>>>>> <14898981-27c9-8a85-91c8-77c93a931278 at connect2id.com>
> >>>>>>> Content-Type: text/plain; charset="utf-8"
> >>>>>>>
> >>>>>>> Hi Filip,
> >>>>>>>
> >>>>>>> My concern is that relying on the client_id opens up post logout
> >>>>>>> redirection to potential misuse.
> >>>>>>>
> >>>>>>> IMO the OP shouldn't be picking any redirections if cannot be
> >>>>>>> sure, to a satisfactory degree, that it's the legitimate RP
> >>>>>>> making the call.
> >>>>>>>
> >>>>>>> The ID token isn't really a substitute for proper RP
> >>>>>>> authentication, but it's some way towards that.
> >>>>>>>
> >>>>>>> A JWS request might help here, but it's probably too much to ask
> >>>>>>> from RPs.
> >>>>>>>
> >>>>>>> Vladimir
> >>>>>>>
> >>>>>>>
> >>>>>>>> On 20/07/18 11:10, Filip Skokan via Openid-specs-ab wrote:
> >>>>>>>> New issue 1032: rp-initiated logout - proposal for client_id
> >>>>>>>> parameter
> >>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bitbucket.
> >>>>>>>> org_openid_connect_issues_1032_rp-2Dinitiated-2Dlogout-2Dpropos
> >>>>>>>> al-2Dfor-2Dclient-5Fid&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qI
> >>>>>>>> rMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=
> >>>>>>>> qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=XPovg09GXpcxWGyel
> >>>>>>>> D8zKNCUzJP71dmPh3bNGNK7k5w&e=
> >>>>>>>>
> >>>>>>>> Filip Skokan:
> >>>>>>>>
> >>>>>>>> I'd like to request that a parameter (optional or required?)
> >>>>>>>> client_id is defined for rp-initiated logout request.
> >>>>>>>>
> >>>>>>>> rationale:
> >>>>>>>>
> >>>>>>>> Currently the id_token_hint is the only way of identifying the
> >>>>>>>> client that's making the request. In scenarios where a client
> >>>>>>>> does not yet have an id_token but makes a request to
> >>>>>>>> authenticate which fails (e.g.
> >>>>>>>> due to being requested with essential sub claim through claims)
> >>>>>>>> the next step will be to trigger an rp initiated logout with a
> >>>>>>>> registered post_logout_redirect_uri but without an
> >>>>>>>> id_token_hint. This can be problematic for OP deployments with
> >>>>>>>> a high number of clients as it is not efficient or sometimes
> >>>>>>>> even not possible to iterate over all of them to see if this
> >>>>>>>> post_logout_redirect_uri is whitelisted or not.
> >>>>>>>> Hence the client_id parameter to make this lookup possible and
> >>>>>>>> efficient.
> >>>>>>>>
> >>>>>>>> Further processing may be defined such as if both client_id and
> >>>>>>>> id_token_hint are provided the audience of the id_token_hint
> >>>>>>>> must include the client_id etc.
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> -------------- next part -------------- A non-text attachment
> >>>>>>> was scrubbed...
> >>>>>>> Name: smime.p7s
> >>>>>>> Type: application/pkcs7-signature
> >>>>>>> Size: 4002 bytes
> >>>>>>> Desc: S/MIME Cryptographic Signature
> >>>>>>> URL:
> >>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openi
> >>>>>>> d.net_pipermail_openid-2Dspecs-2Dab_attachments_20180720_00f40e9
> >>>>>>> 4_attachment-2D0001.p7s&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qI
> >>>>>>> rMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=q
> >>>>>>> JYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=eTHo7f8tNiakUT3d8Pk
> >>>>>>> F8AQgSq44lpjr4_2Y7S8skp4&e=>
> >>>>>>>
> >>>>>>> ------------------------------
> >>>>>>>
> >>>>>>> Message: 4
> >>>>>>> Date: Fri, 20 Jul 2018 13:16:52 +0200
> >>>>>>> From: Filip Skokan <panva.ip at gmail.com>
> >>>>>>> To: Vladimir Dzhuvinov <vladimir at connect2id.com>
> >>>>>>> Cc: "openid-specs-ab at lists.openid.net Ab"
> >>>>>>>  <openid-specs-ab at lists.openid.net>
> >>>>>>> Subject: Re: [Openid-specs-ab] Issue #1032: rp-initiated logout
> >>>>>>> -  proposal for client_id parameter (openid/connect)
> >>>>>>> Message-ID:
> >>>>>>> 
> >>>>>>> <CALAqi_8w2uvCd9R39YQpL-QxT7srCTvgpQvqkGXnrfo80owEFw at mail.gmail.
> >>>>>>> com>
> >>>>>>> Content-Type: text/plain; charset="utf-8"
> >>>>>>>
> >>>>>>> Hello Vladimir,
> >>>>>>>
> >>>>>>> The OP is advised to render a prompt for the end-user in those
> >>>>>>> cases where post_logout_redirect_uri is not provided. And
> >>>>>>> there's no mention of ignoring the post_logout_redirect_uri
> >>>>>>> param if id_token_hint is missing.
> >>>>>>>
> >>>>>>> Currently:
> >>>>>>>
> >>>>>>>> post_logout_redirect_uri
> >>>>>>>> OPTIONAL. URL to which the RP is requesting that the End-User's
> >>>>>>>> User Agent be redirected after a logout has been performed. The
> >>>>>>>> value MUST have been previously registered with the OP, either
> >>>>>>>> using the post_logout_redirect_uris Registration parameter or
> >>>>>>>> via another mechanism.
> >>>>>>>> If supplied, the OP SHOULD honor this request following the
> >>>>>>>> logout.
> >>>>>>>
> >>>>>>>
> >>>>>>> No mention of ignoring the value if id_token_hint is not
> >>>>>>> provided.
> >>>>>>>
> >>>>>>> and under security considerations, the advise to prompt.
> >>>>>>>
> >>>>>>> The id_token_hint parameter to a logout request can be used to
> >>>>>>> determine
> >>>>>>>> which RP initiated the logout request. Logout requests without
> >>>>>>>> a valid id_token_hint value are a potential means of denial of
> >>>>>>>> service; therefore, OPs may want to require explicit user
> >>>>>>>> confirmation before acting upon them.
> >>>>>>>
> >>>>>>>
> >>>>>>> Supplying a client_id does not change a potential extra OP
> >>>>>>> policy that id_token_hint must be provided if it choses to do
> >>>>>>> so, it simply makes post_logout_redirect_uri lookup possible in
> >>>>>>> cases where loading all uris or clients into memory is not
> >>>>>>> possible/is inefficient or can't query for all valid uris for
> >>>>>>> the same reasons.
> >>>>>>>
> >>>>>>> Best,
> >>>>>>> *Filip*
> >>>>>>>
> >>>>>>>
> >>>>>>> On Fri, Jul 20, 2018 at 1:01 PM Vladimir Dzhuvinov via
> >>>>>>> Openid-specs-ab < openid-specs-ab at lists.openid.net> wrote:
> >>>>>>>
> >>>>>>>> Hi Filip,
> >>>>>>>>
> >>>>>>>> My concern is that relying on the client_id opens up post
> >>>>>>>> logout redirection to potential misuse.
> >>>>>>>>
> >>>>>>>> IMO the OP shouldn't be picking any redirections if cannot be
> >>>>>>>> sure, to a satisfactory degree, that it's the legitimate RP
> >>>>>>>> making the call.
> >>>>>>>>
> >>>>>>>> The ID token isn't really a substitute for proper RP
> >>>>>>>> authentication, but it's some way towards that.
> >>>>>>>>
> >>>>>>>> A JWS request might help here, but it's probably too much to
> >>>>>>>> ask from RPs.
> >>>>>>>>
> >>>>>>>> Vladimir
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On 20/07/18 11:10, Filip Skokan via Openid-specs-ab wrote:
> >>>>>>>>> New issue 1032: rp-initiated logout - proposal for client_id
> >>>>>>>>> parameter
> >>>>>>>>>
> >>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bitbucket.
> >>>>>>>> org_openid_connect_issues_1032_rp-2Dinitiated-2Dlogout-2Dpropos
> >>>>>>>> al-2Dfor-2Dclient-5Fid&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qI
> >>>>>>>> rMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=
> >>>>>>>> qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=XPovg09GXpcxWGyel
> >>>>>>>> D8zKNCUzJP71dmPh3bNGNK7k5w&e=
> >>>>>>>>>
> >>>>>>>>> Filip Skokan:
> >>>>>>>>>
> >>>>>>>>> I'd like to request that a parameter (optional or required?)
> >>>>>>>>> client_id
> >>>>>>>> is defined for rp-initiated logout request.
> >>>>>>>>>
> >>>>>>>>> rationale:
> >>>>>>>>>
> >>>>>>>>> Currently the id_token_hint is the only way of identifying the
> >>>>>>>>> client
> >>>>>>>> that's making the request. In scenarios where a client does not
> >>>>>>>> yet have an id_token but makes a request to authenticate which
> >>>>>>>> fails (e.g.
> >>>>>>>> due to
> >>>>>>>> being
> >>>>>>>> requested with essential sub claim through claims) the next
> >>>>>>>> step will be to trigger an rp initiated logout with a
> >>>>>>>> registered post_logout_redirect_uri but without an
> >>>>>>>> id_token_hint. This can be problematic for OP deployments with
> >>>>>>>> a high number of clients as it is not efficient or sometimes
> >>>>>>>> even not possible to iterate over all of them to see if this
> >>>>>>>> post_logout_redirect_uri is whitelisted or not. Hence the
> >>>>>>>> client_id parameter to make this lookup possible and efficient.
> >>>>>>>>>
> >>>>>>>>> Further processing may be defined such as if both client_id
> >>>>>>>>> and
> >>>>>>>> id_token_hint are provided the audience of the id_token_hint
> >>>>>>>> must include the client_id etc.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> Openid-specs-ab mailing list
> >>>>>>>> Openid-specs-ab at lists.openid.net
> >>>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openi
> >>>>>>>> d.net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwICAg&c=RoP1YumCX
> >>>>>>>> CgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpu
> >>>>>>>> YqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw
> >>>>>>>> &s=vqMu4wpIOPufViYMGvzTtZtsynYxmLnmUHJCL88jWLY&e=
> >>>>>>>>
> >>>>>>> -------------- next part -------------- An HTML attachment was
> >>>>>>> scrubbed...
> >>>>>>> URL:
> >>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openi
> >>>>>>> d.net_pipermail_openid-2Dspecs-2Dab_attachments_20180720_43cba25
> >>>>>>> d_attachment.html&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65
> >>>>>>> eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsH
> >>>>>>> BZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=KmCCQjnkztIL-CzFEhohJrsvd
> >>>>>>> GwCZtWRDGDfwFTOOTs&e=>
> >>>>>>>
> >>>>>>> ------------------------------
> >>>>>>>
> >>>>>>> Subject: Digest Footer
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Openid-specs-ab mailing list
> >>>>>>> Openid-specs-ab at lists.openid.net
> >>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid
> >>>>>>> .net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwICAg&c=RoP1YumCXCg
> >>>>>>> aWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqP
> >>>>>>> kAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=v
> >>>>>>> qMu4wpIOPufViYMGvzTtZtsynYxmLnmUHJCL88jWLY&e=
> >>>>>>>
> >>>>>>>
> >>>>>>> ------------------------------
> >>>>>>>
> >>>>>>> End of Openid-specs-ab Digest, Vol 390, Issue 9
> >>>>>>> ***********************************************
> >>>>>> _______________________________________________
> >>>>>> Openid-specs-ab mailing list
> >>>>>> Openid-specs-ab at lists.openid.net
> >>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.
> >>>>>> net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwICAg&c=RoP1YumCXCgaW
> >>>>>> HvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI
> >>>>>> 1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=vqMu4
> >>>>>> wpIOPufViYMGvzTtZtsynYxmLnmUHJCL88jWLY&e=
> >>>>>>
> >>>>>
> >>>> _______________________________________________
> >>>> Openid-specs-ab mailing list
> >>>> Openid-specs-ab at lists.openid.net
> >>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.ne
> >>>> t_mailman_listinfo_openid-2Dspecs-2Dab&d=DwICAg&c=RoP1YumCXCgaWHvlZ
> >>>> YR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN
> >>>> 4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=vqMu4wpIOPufV
> >>>> iYMGvzTtZtsynYxmLnmUHJCL88jWLY&e=
> >>
> >>
> >
> >
> > ------------------------------
> >
> > Subject: Digest Footer
> >
> > _______________________________________________
> > Openid-specs-ab mailing list
> > Openid-specs-ab at lists.openid.net
> > http://lists.openid.net/mailman/listinfo/openid-specs-ab
> >
> >
> > ------------------------------
> >
> > End of Openid-specs-ab Digest, Vol 390, Issue 11
> > ************************************************
>  
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20180723/b421fab0/attachment-0001.html>


More information about the Openid-specs-ab mailing list