[Openid-specs-ab] OIDC Session Management and third party cookie blocking

Thu Sep 1 18:43:16 UTC 2022

This pattern IS TRACKING by the IdP of accesses by the user to the RP.
That is considered to be a problem in the case of the mDL.
It seems that the concept of RP Refresh is a topic that should be
considered independently of these various use cases as it needs to be
controlled by the user agent in any case.
Perhaps an entirely separate standard for RP Refresh.
Be the change you want to see in the world ..tom

On Tue, Aug 30, 2022 at 6:13 PM Jake Feasel via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> While this concern is important, if we follow it through completely it
> kills the entire auth code grant for the same reasons. Looking at it from
> the browser point-of-view, the auth code grant is just some redirection
> across domains involving the transmission of an opaque "code" generated by
> the OP back to the RP, followed by an additional call from the RP to the OP
> passing it back; who is to say that this code isn't used for tracking users
> across sites?
>
> "The browser people don’t seem to care about that at the moment." - There
> is a good reason why the privacy-conscious should not be opposed to this
> general technique (both the auth code and the proposed session check
> grants). Both grants can only work in a third-party cookie blocking
> environment if the browser is redirected through the OP at the top-level
> (i.e. as a first party interaction). I believe this is the critical point
> that shifts the usage from "nefarious" to "legitimate".
>
> Put another way - if a privacy-abusing marketing company wanted to try to
> copy this pattern for their own nefarious purposes, they would have to
> require every page they advertise on to have a top-level redirect for all
> visitors through their own domain and back again (passing the requisite
> tracking id back in the URL). I feel like this extremely obtrusive pattern
> would not be acceptable for most pages that just want to show ads - it's
> only acceptable in the case of authentication because the site and the user
> have very tangible benefits from the interruption in flow associated with
> logging in.
>
> I think we are on safe ground here, in terms of what patterns are likely
> to be shut down in the future. As such I would like to continue with this
> "session_check" grant proposal.
>
> Thanks
>
>
>
> On Wed, Aug 10, 2022 at 3:25 AM Mischa Salle via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
>
>> On Tue, Aug 09, 2022 at 06:39:27PM +0000, Nicole Roy via Openid-specs-ab
>> wrote:
>> > My concern would be that a browser employing “Intelligent Tracking
>> Prevention” would see the POST of the SID as tracking and prevent it. Of
>> course, doing so breaks all sorts of other things, but the browser people
>> don’t seem to care about that at the moment.
>>
>> probably would have the same problems with "nonce" and "state" then?
>> Plus makes one wonder whether these three could not have been a single
>> parameter?
>>
>> Mischa
>>
>> > > On Aug 2, 2022, at 4:30 PM, Jake Feasel via Openid-specs-ab <
>> openid-specs-ab at lists.openid.net> wrote:
>> > >
>> > > This topic has been raised before, but based on the traffic from this
>> list it seems to not be going anywhere. I would like to revive it.
>> > >
>> > > I had a quick talk at Identiverse this year covering the OIDC Session
>> Management draft spec, in particular my take on the upcoming
>> "Cookiepocalypse" and how it will render the current draft completely
>> obsolete. You can see my slides here:
>> https://docs.google.com/presentation/d/1uU3KvK6ayTpjB2OEmrSqQnUdJDPSdfxxetJrks1czvI/edit#slide=id.g11aa5093f19_0_63
>> <
>> https://docs.google.com/presentation/d/1uU3KvK6ayTpjB2OEmrSqQnUdJDPSdfxxetJrks1czvI/edit#slide=id.g11aa5093f19_0_63
>> >
>> > >
>> >
>> > [snip]
>> >
>> > > The OP will include the "sid" claim (as defined in the Front and
>> Back-channel logout drafts) as a claim in the id_token used in an auth_code
>> grant. This "sid" value will be included in a POST request to the "token"
>> endpoint on the OP on a periodic basis (likely prompted from user activity
>> within the RP). It would like something like so (note the absence of a
>> cookie in this request):
>> > >
>> > >   POST /token HTTP/1.1
>> > >   Host: server.example.com <http://server.example.com/>
>> > >   Content-Type: application/x-www-form-urlencoded
>> > >   Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
>> > >
>> > >   grant_type=session_check&sid=1234xyz
>> > >
>> > > The response code from this could be a 401 if the sid is not
>> associated with a valid OP session, or 200 if it is. The response body in
>> the case of a 200 could include a new id_token with updated session claims
>> (to provide better context for when the session expires or if other
>> important details about the session change).
>> > >
>> >
>> > [snip]
>> >
>>
>>
>>
>> > _______________________________________________
>> > Openid-specs-ab mailing list
>> > Openid-specs-ab at lists.openid.net
>> > https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>
>> --
>> Nikhef                      Room  1.14
>> Science Park 110            Tel.  +31-6-4681 2202
>> 1098 XG Amsterdam           Fax   +31-20-592 5155
>> The Netherlands             Email msalle at nikhef.nl
>>   __ .. ... _._. .... ._  ... ._ ._.. ._.. .._..
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>
>
> --
> [image: ForgeRock] <https://www.forgerock.com/> *Jake Feasel*
> Sr. Product Manager, IDM |  ForgeRock
> *e* jake.feasel at forgerock.com <firstname.lastname at forgerock.com>
> *twitter* jakefeasel  |  *web* www.forgerock.com
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://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/20220901/72bfb54c/attachment.html>