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

Nat Sakimura sakimura at gmail.com
Fri Jul 27 04:40:02 UTC 2018


Mike,

The OpenID Process is available from
https://openid.net/intellectual-property/
The direct links are:

OpenID Process – Word Doc
<https://openid.net/wordpress-content/uploads/2010/01/OpenID_Process_Document_December_2009_Final_Approved.doc>
OpenID Process – PDF
<https://openid.net/wordpress-content/uploads/2010/01/OpenID_Process_Document_December_2009_Final_Approved.pdf>

Since you have agreed to the Contribution Agreement which fully
incorporates it, you must have read it.

These processes have been there and clearly published since December 2009.

The WG process is defined as intra-WG decisions.
It is a consensus (not unanimous) process. We almost never vote. Needing to
vote actually is a sign of failure. That's in line with the WTO TBT Treaty
for the process to be followed by an international standardization
organization.

Let me quote this from the process document:

*3.3 Consensus. Consensus is a core WG value. To promote consensus, Editors
should encourage consideration and resolution of all legitimate comments of
Contributors. All Intra-WG decisions will optimally be made by determining
consensus, without formal vote. Editor(s) will assess consensus without a
formal vote and, when a proposal is pending, may interpret silence of those
who have received proper notice (or who are present) as assent. Consensus
does not imply unanimity, although there should be substantial support for
consensus decisions. For Intra-WG, Core Decisions, consensus should
reasonably reflect the opinion of a Supermajority of Contributors to the
applicable WG, after reasonable inquiry by the Editors. For Intra-WG,
Non-Core Decisions, consensus should reflect the opinion of a majority of
Contributors actually expressing an opinion. . If a decision cannot be made
by consensus, the WG should defer decision until consensus can be reached.
If deferral would prejudice a WG’s work, however, the Editor(s) may call a
formal vote in accordance with §3.4. *

In this particular incident, I, as a chair of AB/Connect WG,  had to do
some digging up if the process was followed. (Note: I am not an Editor.) It
took longer than I thought. Sorry for the delay.

According to my research, the editors solicited comments on January 31 on
the draft both in the form of email [1] and as an openid.net post [2].

[1] http://lists.openid.net/
<http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20180129/006706.html>
pipermail/openid-specs-ab/
<http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20180129/006706.html>
Week-of-Mon-20180129/006706.
<http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20180129/006706.html>
html
<http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20180129/006706.html>
[2] http://openid.net/2018/01/31/
<http://openid.net/2018/01/31/openid-connect-federation-draft-04/>
openid-connect-federation-
<http://openid.net/2018/01/31/openid-connect-federation-draft-04/>draft-04/
<http://openid.net/2018/01/31/openid-connect-federation-draft-04/> .

These counts as proper notices.

There has been no response to it.

As quoted above, Section 3.3 of the process document states:

*Editor(s) will assess consensus without a formal vote and, when a proposal
is pending, may interpret silence of those who have received proper notice
(or who are present) as assent. *

It was only after the 45 days public review for the implementer's draft has
been announced that the comments started to come in.
For those comments, the editors agreed to address them in the next
revision. As a chair, I would strongly advise the commenters to post those
issues in the issue tracker so that editors will not forget about them.

Note that all the drafts are out there for technical comments solicitation.
Otherwise, there is no value in having it there.
Editorial comments can wait until later stage but technical comments need
to be in as soon as it is noticed.
You can always file issues in the tracker. *It is the responsibility of the
WG members to do so the soonest possible*.
Then, it will be treated.

If you are not sure if that is a valid issue and first want to consult the
list or calls, you can do so as well.
But, at the end of the day, issues have to be filed to the tracker if it
needs treatment.
These will be discussed in the calls as well as in the tracker.

As Mike Jones apologized in the list, for this particular case, the
notification from the editors to the WG did not go as clear as I had
wished. That’s one of the reasons why it took me so long to dig things up.
It could have been done better.

However, I would strongly object to your comment that the WG processes are
not published nor WG consensus is almost never called.
The process has always been published and is fully incorporated in the
contribution agreement *that you have signed*.

“WG consensus call” is not necessary as it is something that editor should
measure. However, in many cases, for the measurement purposes, editors have
been calling for it. For example, I can find such note from Mike Jones for
logout implementer's drafts sent out on Jan 26, 2017. Or at least for FAPI
WG, these can be evidently read from the meeting notes as well as on the
list archive.

Best regards,

Nat Sakimura


On Sat, Jul 21, 2018 at 1:53 AM Mike Schwartz via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> "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=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=hpgFrnPt9eP5DCbWWSkhzDGGgkCLxqsYB5OxNoFp674&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=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=vqMu4wpIOPufViYMGvzTtZtsynYxmLnmUHJCL88jWLY&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.prod.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=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&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.org_openid_connect_issues_1032_rp-2Dinitiated-2Dlogout-2Dproposal-2Dfor-2Dclient-5Fid&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=XPovg09GXpcxWGyelD8zKNCUzJP71dmPh3bNGNK7k5w&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-2Dproposal-2Dfor-2Dclient-5Fid&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=XPovg09GXpcxWGyelD8zKNCUzJP71dmPh3bNGNK7k5w&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=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=eTHo7f8tNiakUT3d8PkF8AQgSq44lpjr4_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-2Dproposal-2Dfor-2Dclient-5Fid&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=XPovg09GXpcxWGyelD8zKNCUzJP71dmPh3bNGNK7k5w&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=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&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.openid.net_pipermail_openid-2Dspecs-2Dab_attachments_20180720_43cba25d_attachment.html&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=KmCCQjnkztIL-CzFEhohJrsvdGwCZtWRDGDfwFTOOTs&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=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=vqMu4wpIOPufViYMGvzTtZtsynYxmLnmUHJCL88jWLY&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=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=vqMu4wpIOPufViYMGvzTtZtsynYxmLnmUHJCL88jWLY&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=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=vqMu4wpIOPufViYMGvzTtZtsynYxmLnmUHJCL88jWLY&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.outlook.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=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=hpgFrnPt9eP5DCbWWSkhzDGGgkCLxqsYB5OxNoFp674&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=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=vqMu4wpIOPufViYMGvzTtZtsynYxmLnmUHJCL88jWLY&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.prod.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=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&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.org_openid_connect_issues_1032_rp-2Dinitiated-2Dlogout-2Dproposal-2Dfor-2Dclient-5Fid&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=XPovg09GXpcxWGyelD8zKNCUzJP71dmPh3bNGNK7k5w&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-2Dproposal-2Dfor-2Dclient-5Fid&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=XPovg09GXpcxWGyelD8zKNCUzJP71dmPh3bNGNK7k5w&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=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=eTHo7f8tNiakUT3d8PkF8AQgSq44lpjr4_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-2Dproposal-2Dfor-2Dclient-5Fid&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=XPovg09GXpcxWGyelD8zKNCUzJP71dmPh3bNGNK7k5w&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=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&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.openid.net_pipermail_openid-2Dspecs-2Dab_attachments_20180720_43cba25d_attachment.html&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=KmCCQjnkztIL-CzFEhohJrsvdGwCZtWRDGDfwFTOOTs&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=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=vqMu4wpIOPufViYMGvzTtZtsynYxmLnmUHJCL88jWLY&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=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=vqMu4wpIOPufViYMGvzTtZtsynYxmLnmUHJCL88jWLY&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=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=vqMu4wpIOPufViYMGvzTtZtsynYxmLnmUHJCL88jWLY&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
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20180727/29f93e3e/attachment-0001.html>


More information about the Openid-specs-ab mailing list