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

John Bradley ve7jtb at ve7jtb.com
Mon Mar 2 13:31:14 UTC 2015


Yes I think it can be useful for both.  I prefer not to have two smiler back channel ways to do it if possible.  

Sent from my iPhone

> On Mar 2, 2015, at 2:24 PM, Torsten Lodderstedt <torsten at lodderstedt.net> wrote:
> 
> 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