[Openid-specs-ab] Please Either ABSTAIN or OBJECT from the Federation Spec Vote

Mike Schwartz mike at gluu.org
Fri Jul 20 14:15:55 UTC 2018


> 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 http://openid.net/connect/   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://www.linkedin.com/in/nynymike/

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
> 	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 (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
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>> 
> 
> 
> ------------------------------
> 
> 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://bitbucket.org/openid/connect/issues/1032/rp-initiated-logout-proposal-for-client_id
> 
> 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://bitbucket.org/openid/connect/issues/1032/rp-initiated-logout-proposal-for-client_id
>> 
>> 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:
> <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20180720/00f40e94/attachment-0001.p7s>
> 
> ------------------------------
> 
> 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://bitbucket.org/openid/connect/issues/1032/rp-initiated-logout-proposal-for-client_id
>> >
>> > 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
>> 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/20180720/43cba25d/attachment.html>
> 
> ------------------------------
> 
> 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 9
> ***********************************************


More information about the Openid-specs-ab mailing list