Paul Hethmon | 3 May 23:20 2016

[OpenID] claims vs scopes vs extra

In doing some of my final testing prior to certification I’ve come across one behavior of the
certification tool that puzzles me. Specifically in regards to the response content to the UserInfo
endpoint. It’s very clear from the specification that if I request a particular scope, what standard
claims should be returned. Likewise, if a specific claim is requested then that claim is to be returned.
Any extra claims about the user also would not be returned.

However, just in my coding, I had my UserInfo endpoint always include a few claims that are more “metadata”:


For the certification tool, it’s happy with the Scope tests returning these claims. But its not happy
when they are returned via the “essential claim” test. So to me that appears inconsistent in
behavior. After figuring this out, I went reading through the core document and couldn’t find an answer
either way. There is a reference in 5.3.2 that the response SHOULD contain iss and aud if it is signed or
encrypted. I’m not actually doing either (yet).

I can’t find a reason (or remember one) for including iat and exp in the UserInfo response. I’m thinking
I must have done it from a cut/paste code perspective.

So, some specific questions:

1. Should iat or exp every be included in a UserInfo response? I am thinking they don’t make sense.
2. Should the certification tool care or not care about extra claims?


(Continue reading)

Phil Hunt | 1 Apr 20:10 2016

[OpenID] Identity Events - GitHub site

In order to provide more time for access prior to the Tuesday discussion (during the SCIM slot at IETF95), I have posted all of the drafts that have been worked on in github at:

The following drafts are available:

draft-hunt-idevent-token-00 (published to IETF) - The event token format based on JWT
draft-hunt-idevent-scim-00 (published to IETF) - Event token extension for SCIM
draft-hunt-idevent-distribution-00 (unpublished) - Metadata and methods for distributing events

Also available (historical only):
draft-hunt-scim-notify-00 (published to IETF) - An old SCIM submission for historical purposes.
draft-hunt-idevent-subscription-00 - An initial re-work of notify. Replaced by draft-hunt-idevent-distribution.

As I mentioned in an earlier email this week, the distribution draft removes all of the protocol around how subscriptions are managed and updated. It only defines the metadata and sets up a registry for defining distribution methods.  The draft includes the following methods so far:
 - webCallback - Where the publisher uses HTTP POST to distribute events to registered subscriber
 - poll - Where a subscriber uses HTTP GET to pick up events at a subscriber endpoint from the publisher.

This draft is still very preliminary, but I think it does serve the purpose of getting discussion going. It also removes all
of the SCIM specific semantics and focuses on general JSON and JWT formatted messages.  I will publish the distribution draft on Monday when the submission window re-opens. 

The work presented here has not yet been specifically implemented but is strongly informed based on feedback from current production systems and experience.

Thanks for your comments and feedback. 

general mailing list
general <at>
boris8479 | 1 Apr 01:31 2016

[OpenID] Some thoughts on Open ID Connect Session

Hi Community,


My name is Boris Georgiev and I am in charge for Application Security in a large financial institution. I do appreciate bringing up the standard Open ID Connect. I am excited after so many years, finally there is a standard. However, when facing up with Open ID Connect Session spec, I started to experience some disappointments.


Section 3 says: “In Open ID Connect, the session at the RP typically starts when the RP validates the End-User's ID Token”. In my mind, as I am trying to protect everything, I am about to receive the session together with the ID token, i.e. via the token API. However, reading further, the spec states that the variable session_state is returned in “the authentication response” which was changed few specifications back from “the authorization response”. The reference to core shows example with the authorization code, and there is no example, showing the code and the session_state together. I was thinking initially that it is my confusion only, however I showed it to other engineers, native English speakers and they were confused too. I do believe this needs to be explained better, which session is which. So far I did not like the fact, that the session state is returned in a redirect via GET request, which we all know its vulnerabilities.


Further, section 4 explains that this is all about session state change notification, so the RP can refresh the ID token, avoiding the network traffic. So far so good. Finally, section 4.2 explains that the session actually is hashed and re-calculated at the OP frame. I think finally, the session is safe. However, to my disbelief, the spec explains that OP frame “may” use a cookie which is not http only, so it can be accessed by a JavaScript. Here I start wondering how people with security regulations similar to mine pass audit.


If the session is passed to the OP frame in some other secure way and if it is not used for any other purpose but for the session change notification, this will solve the problem. However the spec does not list it anywhere as a security concern, neither recommends secure ways. Moreover, I saw open source implementations out there, where the same cookie is driving the Single-Sign-On at the Authorization Server. This means, once the value of this cookie is obtained, it can be used to invoke the authorization API, bypass authentication and if implicit grant is requested, the attacker can get access tokens. The last safeguard is the callback URL, which can be easily bypassed by overwriting the local hosts file. Sounds like a complex and almost impossible, however in the financial industry the security is attempted to be penetrated by the brightest minds across the globe where patience and persistence can be well awarded. I need just one case like that to end my career. Therefore I do need to think about closing all the gaps and I still cannot find piece, thinking what else can be out there.


I do believe the above security concerns need to be listed in the spec. And I do believe this non http cookie idea needs to be listed in the security concerns, instead of being recommended.


If you need my opinion how it can be improved:


There is already a mechanism to protect token exchange. This is via the authorization code and token API. I thing, passing it from there will eliminate the need of encryption. Then, the session_state can be embedded in the script of the RP frame and comparison/calculation logic to be embedded in the OP frame (not via a cookie). Encryption is great, but one of the goals of OAuth is for authentication/authorization not to be done too often. The solution is acceptable for desktops, powered by the power grid, but for a thin device, one cannot do often encryption operations and expect a great battery life. I do not know if anyone ever considered that and was there any reason not to be pursued.



Boris Georgiev

general mailing list
general <at>
Malithi Edirisinghe | 21 Mar 05:56 2016

[OpenID] [OpenID Connect] Where to send session_state param at authorization code flow

Hi All,

I would like to clarify on, with which response 'session_state' parameter should be sent when supporting OpenID Connect session management in authorization code flow.

As per the specification, session_state parameter should be returned with the authentication response. 
By referring the OpenID Connect Session Management specification and OpenID Connect Core specification, what I understood was that the session_state parameter should be sent along with the authorization code, in the authorization code flow. 
But, when it comes to Open ID Connect, seems there are also assumptions, that authentication response is where the access token and ID token are returned.
So, kindly would like to know whether it should be returned with the authorization code or in the json response where ID token and access token is returned. 



Malithi Edirisinghe
Senior Software Engineer
WSO2 Inc.

Mobile : +94 (0) 718176807
general mailing list
general <at>
Paul Hethmon | 2 Mar 21:48 2016

[OpenID] Auth Request display param question

In section of Core, it details the 4 options for the “display” parameter. While the 4 options
are clear enough, I don’t get the intent of having “page” vs “popup”. If the client has been
redirected to the OP for authentication, there’s a full browser window sitting there, so why ask the OP
to popup something over that? I haven’t found any archived discussion or blogs on the subject and feel I
must totally be missing the point here.

Discussion here or a pointer to something is greatly appreciated.



Paul Hethmon
Chief Software Architect
paul.hethmon <at>

general mailing list
general <at>
Paul Hethmon | 27 Jan 23:38 2016

[OpenID] discovery url vs issuer

First, I haven’t seen any traffic from this list since joining a month ago, so if I’m off topic, please
let me know.

I am beginning conformance testing and seeing an unexpected error from the conformance tool. My setup is
that my issuer has a value like:

I’ve got my metadata at this URL:

With support for appending the value “.well-known/openid-configuration”. That returns a metadata
document with my issuer value as above.

Testing gives me:

0.000465 ------------ DiscoveryRequest ------------
0.000496 Provider info discover from ''

0.000503 --> URL:

0.161675 [ERROR] IssuerMismatch:'' != ''

So it’s obvious the tool is requiring the issuer value to be where the discovery request goes to and that it match.

Where in the spec does it say that? I’m not finding it. In the OpenID Connect Discovery 1.0 (errata set 1),
section 3 says:

REQUIRED. URL using the https scheme with no query or fragment component that the OP asserts as its Issuer
Identifier. If Issuer discovery is supported (seeSection 2), this value MUST be identical to the issuer
value returned by WebFinger. This also MUST be identical to the iss Claim value in ID Tokens issued from
this Issuer.

Is that where the match comes from? If I do Discovery, then the WebFinger value MUST match? Since that value
is the location of the metadata, then that now means that my Issuer value must be the actual URL for Discovery.

From a legacy perspective, it would be better for me to not have the issuer be the URL for the Discovery
metadata location, but it if must match in that way, then either I have to change a lot of identifiers or drop Discovery.



Paul Hethmon
Chief Software Architect
paul.hethmon <at>

general mailing list
general <at>
John Bradley | 18 Jan 14:47 2016

[OpenID] Opened Summit in Santiago

We are organizing a one day summit in Santiago Chile at the University de Chile on May 31, before the IETF
meeting in Buenos Aires the following week.

I will let people know once the eventbrite page for registrations is ready. 

This will be our first OPenID summit in the Southern hemisphere.

John B.
Attachment (smime.p7s): application/pkcs7-signature, 5843 bytes
general mailing list
general <at>
Steve Garing | 7 Dec 11:42 2015

[OpenID] Return Authorities to Client


Is there a standard way to return the authorities to a client?  I haven’t been able to get the authorities returned via standard functionality in the MITREid Connect project and we’d like the clients to have visibility of a users role to determine some client side functionality.

Would it correct to think that the clients can request and extra scope like ‘authorities’ and then provide the authorities in the id_token and from the userinfo endpoint?

general mailing list
general <at>
benutzerlogin | 30 Nov 18:27 2015

[OpenID] How to get started with OpenID


I would like to add OpenID login to my website. More precisely
WargamingID. But I can't find anywhere some kind of tutorial to do so. I
have asked web-masters who are using OpenID/WargamingID for login. I
have asked in several forums. But I don't get an answer. It looks like
OpenID is a big secret only accessible for some IT-professionals.
I'm using Joomla. Bad luck they excluded the OpenID-Extension with
Version 2.

I have read the developer section on OpenID homepage, but that's way to
advanced for me.

Is there anybody who could tell me how to get started as non-professional?

Or is OpenID to sophisticated for the general interested public?

Link to WargamingID API:

Thanks and kind regards,



Marek Mayer
Am Otterberg 73
95032 Hof
home_pw | 30 Oct 22:38 2015

[OpenID] Real estate, energy and openid

A little bit of feel good news.

US residential/commercial regulated real estate standards folks met again, last week. Ever growing, it saw interactions from the once Paraihia-staus "new homes"  folks (with rp dbs of new home data( and even the us federal government (and it's layers of contractors, agencies and govt labs -that I've tried hard to forgot I once work for).

Abways, aside from an solid but standard demo of using micrisoft/owin libs to build openid issuers and "account linking" rps that can also talk to amazon - based an openid issuer, we say something else (on paper) that really charcuterizes the true scope of openid.

For privacy reasons, utility companies don't share meter data with just anyone but a nice initiate is to allow id tokens to not only unlock api guards and meditate Web sessions but authorize unlocking website endpoints (to which that some user guarded website  akready showing other home listing dara might hyperlink). To be exact, to autorize some contractor vendor guarding release of some other utility companies (smart) meter data from yr house, to release the data (and rely on the Id tojen, for privacy audit puposes).

Just though I'd share some application domain information, this time based on doe agency folk bringing their govt reach to bear. Hard to say the us national Id initiative is not working...

Sent by Outlook for Android

general mailing list
general <at>
Mike Jones | 10 Sep 08:54 2015

[OpenID] OpenID Connect Back-Channel Logout Specification

A new back-channel OpenID Connect Logout spec has been published at  This can coexist with or be used instead of the front-channel-based Session Management and HTTP-Based Logout specifications.


The abstract for the new specification states:

This specification defines a logout mechanism that uses back-channel communication between the OP and RPs being logged out; this differs from front-channel logout mechanisms, which communicate logout requests from the OP to RPs via the User Agent.


This completes publication of the three planned OpenID Connect logout mechanisms:  two that communicate on the front-channel through the User Agent (browser) and this one that communicates on the back-channel, without involving the User Agent.  See the Introduction for a discussion of the upsides and downsides of the different logout approaches.  As much as we'd like there to be a single logout solution, both experience and extensive discussions led us to the conclusion that there isn't a feasible one-size-fits-all approach.


Reviews of the new (and existing!) specifications are welcomed.


Thanks to John Bradley, Pedro Felix, Nat Sakimura, Brian Campbell, and Todd Lainhart for their contributions to the creation of the specification.


                                                            -- Mike


P.S.  This note was also published at and as <at> selfissued.

general mailing list
general <at>