[Openid-specs-ab] Spec call notes 23-Feb-15

Torsten Lodderstedt torsten at lodderstedt.net
Mon Mar 2 13:24:19 UTC 2015


Hi Brian,

>I might humbly suggest that back-channel logout is not something that
>should be standardized at the SSO protocol layer like Connect. It
>strikes
>me as more of the kind of thing that'd be useful as the account level
>and
>more of a "shared signals" or deprovisiniong kind of thing.

I think such a mechanism could also be used as way to notify resource servers in case of access token revocation.

kind regards, 
Torsten.



>
>
>
>On Tue, Feb 24, 2015 at 5:18 AM, John Bradley <ve7jtb at ve7jtb.com>
>wrote:
>
>> I don’t actualy think we need a signed token in the front channel.
>>
>> I am talking about using a signed token in the back channel, but that
>is
>> quite different, as all of the session information needs to be
>derived from
>> the token as the RP has no session cooke.
>>
>> In the front channel there are two issues.
>>
>> 1 what account to sign out if there is more than one logged in from
>the IdP
>> 2 is this from the IdP or a cross site request forgery.
>>
>> 1 could be solved by including the subject or a session identifier.
>> 2 The sid alone should be sufficient to stop a XSRF unless the
>id_token
>> has leaked.
>>
>> If you send the sid then you probably don’t need to send the sub.
>(That is
>> where I thought we were going)
>>
>> I think trying to OAuth protect  the clients endpoint with a bearer
>token
>> might be an advanced option, but that would need to be in a query
>parameter
>> to be sent from a image tag.
>> Is setting up a way for clients to provision a AS with a AT per
>subject
>> worth while.   If it is one AT for all subjects then it leaks right
>away
>> and is no real good to prevent xsrf.
>>
>> Modifying the authorization request to include a token is possible,
>but I
>> am not sure how necessary.
>>
>> John B.
>>
>> On Feb 24, 2015, at 1:38 AM, Torsten Lodderstedt
><torsten at lodderstedt.net>
>> wrote:
>>
>> I don't understand why you want to invite a new token concept for the
>> logout. First there was a sid. The sid alone is not enough (if the
>same
>> value is used among RPs in the same session), therefore you need to
>> introduce an audience and a digital signature. This is getting more
>complex
>> with every iteration.
>>
>> From a conceptual perspective, the challenge we are facing is the OP
>wants
>> to send a request to a protected resource (logout endpoint at the
>RP).
>> Sounds familiar? Yes, because this is classic OAuth with the OP
>taking the
>> role of the client.
>>
>> I would therefore suggest to let the RP register the token it wants
>to get
>> its logout endpoint invoked with. One could also use RFC 6750
>mechanisms
>> (or even pop) to carry the token in the actual logout request. The
>> advantage of this design: this token is opaque to the OP. There is no
>need
>> to specify it. The token design and how to identify the respective
>session
>> at the RP is at the RP's discretion. It could just be a reference to
>its
>> session database. It also could be a JWT.
>>
>> kind regards,
>> Torsten.
>>
>> Am 24. Februar 2015 03:45:34 MEZ, schrieb John Bradley
><ve7jtb at ve7jtb.com
>> >:
>>
>>> My point was not that audience was not needed, but rather that it
>could
>>> be a different audience to differentiate between the login and sign
>out
>>> tokens.
>>> That WAY the sign out tokens would not be accepted as login tokens. 
> eg
>>> the logout_uri rather than the client_id as a posable example.
>>>
>>> John B.
>>>
>>> On Feb 23, 2015, at 6:32 PM, Mike Jones
><Michael.Jones at microsoft.com>
>>> wrote:
>>>
>>> Spec call notes 23-Feb-15
>>>
>>>
>>> Nat Sakimura
>>>
>>> Mike Jones
>>>
>>> Brian Campbell
>>>
>>> Edmund Jay
>>>
>>> John Bradley
>>>
>>>
>>> Agenda
>>>
>>>                Use of Pragma: no-cache in Form Post Response Mode
>>>
>>>                Logout
>>>
>>>                Certification
>>>
>>>
>>> Use of Pragma: no-cache in Form Post Response Mode
>>>
>>>                Brian believes the only change needed is to remove
>the
>>> "Pragma: no-cache"
>>>
>>>                He believes that "Cache-Control: no-store" also
>performs a
>>> "Cache-Control: no-cache"
>>>
>>>                               Mike will confirm this
>>>
>>>                Then Mike will make the change and update the blog
>post
>>>
>>>                Later in the call, Brian pointed out that we should
>have
>>> normative text about not caching the result
>>>
>>>                               He will propose a sentence to add
>>>
>>>
>>> Logout
>>>
>>>                When using the Session ID on the front channel,
>you're
>>> only picking from among those that are live in the browser
>>>
>>>                An alternative to putting "sid" and "iss" as query
>>> parameters is to them in a JWT
>>>
>>>                               But it should not be a legal ID Token,
>so
>>> perhaps shouldn't have a subject
>>>
>>>                               John pointed out that we should at
>least
>>> consider whether an audience would be needed
>>>
>>>                John will be working on a back channel logout spec
>also
>>> using the Session ID
>>>
>>>                               We should try to have these be as
>close to
>>> one another as reasonably possible
>>>
>>>                               He's on his way to Barcelona for MWC,
>so
>>> this may not happen for a bit
>>>
>>>                People agreed that the differentiation between image
>and
>>> iframe GETs must happen at registration time
>>>
>>>                The query parameters still need to be reviewed
>>>
>>>
>>> Certification
>>>
>>>                Roland now has testing up on the Symantec hosts
>>>
>>>                A team member of Roland's created an OP
>self-registration
>>> page at https://op.certification.openid.net:60000/
>>>
>>>                               When you select dynamic configuration,
>the
>>> answer to the first question is the issuer path (this isn't obvious)
>>>
>>>                               Mike will file some bugs on clarifying
>how
>>> the tool works
>>>
>>>                People doing testing should migrate over to the
>official
>>> server
>>>
>>>                This also means that Roland can now also put up the
>RP
>>> tests
>>>
>>>                Breno should be getting back to us within a week or
>so on
>>> how long it will take them to create a conforming implementation
>>>
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>>>
>> --
>> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
>> gesendet.
>>
>>
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.


More information about the Openid-specs-ab mailing list