[Openid-specs-ab] Minutes of Connect AB Call Aug 8

Phil Hunt phil.hunt at oracle.com
Wed Aug 10 17:03:53 UTC 2016

Notes for Connect call.  Please let me know of any corrections.

*Next working group call is on Thursday next week on Aug 18th at 7AM Pacific time.


Nat Sakimura
John Bradley
George Fletcher
Prateek Mishra
Phil Hunt

Nat regarding agenda:

This conversation is in part a continuation of previous call (RISC) as well as EAP drafts. Backchannel and federation spec.

Nat: Any discussion on EAP drafts from last week?
  - the drafts were adopted and people were encouraged to read them according to Nat
No discussion.

Backchannel Logout and ID-Events Discussion.

Nat/John?: We have an issue where ID Tokens and JWTs have a lot of fuzzy overlap. Phil had previously pointed out that figuring out that something is not an ID Token is looking for the absence of something.  Nat indicated he’s long advocated for token type field.

Should we keep using subject in an event, when it may not be the sub as defined by OpenID Connect?  Further that the issuer may not be related to the issuer of the subject. One problem is that any field not understood by the parser would be ignored. Thus it might not be a good idea to re-use subject in the top level.

One idea is to leave sub out of the top level but have sub in the event specific data. “iss” can also be repeated.  John suggested maybe it would be a good idea to rename the attribute.  John mused maybe Mike meant use the id token format, but not literally use the id token.

Prateek: if you look at security event format, it is typically labelled as an observation.  Does that distinguish from an ID Token?

Maybe the id-event envelope should just be an envelop. The individual event be left to define its claims. Separate the two layers. 

John suggested, for logout we should avoid use of the term session and should use token revocation [as in revoke the id token].

John and Phil discussed if two event could be embedded in a message:  e.g. a SCIM account reset and a RISC account reset, then each could have their own attributes and slightly different addressing in the same JWT.  [It was not clear that this is a good thing. The general feeling was keep separate].

John and George discussed the different natures of logout/revocation. If you say revoke a token, is it based on a user action or a devops action?  Are there differences in semantics? 

In the front-channel you rarely want to say revoke this session. But in the back-channel, you may have a specific api call. 

Lot of discussion around how logouts occur and the different nature of related events like account resets, lock-outs, etc. 

What are the difference when the session is on a mobile app vs. a web app is revoked? Is it the same or different.

George, when a party receives a notification that a token has been revoked at Facebook, how should it interpret it?  Does it matter in every case. I don’t know what you do if SFDC is the IDP which is chained to the enterprise.  What happens when a user logs out at a root IDP vs at a chained IDP at SFDC?

George suggested maybe we put together some examples, and share them on the list.  

Lots of discussion on whether to send a sub or jti.  If all sessions to be revoked would a multi-valued “jti” be sent or would multiple events be sent?

George. If all we are talking about is just logout.  If you want to include the concept of a user revoking at token.   

John…if the AS doesn’t send an event to the RS, then the RS is forced to poll constantly.

George, does the AS have to track the type of client that is receiving logins and thus the type of notifications it needs?  

John:  Yes. This would be mostly handled with registration.

George: the issue becomes, for the AS, we have an SP, but its federated with AOL, Ping or whatever. 

John: given sufficient generics for subject and scopes we could do the same thing for SAML.

George: There is a model where the SP is relying on the OP to be its issuer.  Then yo u have the case where the OP is acting as an AS.  Are those cases the same?

What about multiple SPs leveraging a common IDPs.  So you still want to do a broadcast to the SPs.

The group discussed that Connect is both authorization (for delegated independent access) and interactive SSO.  So the logout may need to differentiate.

If an ID Token is revoked by an originating OP, what should a chaining SP acting as AS do?  

George. We should work on a use-case to describe the different classes of logouts and the different intents.  Frame what we need to solve or not solve.

Meeting wrapped up due to time.


www.independentid.com <http://www.independentid.com/>phil.hunt at oracle.com <mailto:phil.hunt at oracle.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20160810/119678a6/attachment-0001.html>

More information about the Openid-specs-ab mailing list