John Bradley | 2 Aug 23:33 2015

[OpenID] New iGov Working Group Charter proposal.

At the request of a number of Governments, some of whom have OpenID Connect deployments and others that are considering it, we propose to form a new OIDF Working group.

The goal is to have a common deployment profile that can be customized for the needs of both pubic and private sector deployments that require the higher levels of security that OpenID Connect can support.

"The purpose of this working group is to develop a security and privacy profile of the OpenID Connect specifications that allow users to authenticate and share consented attribute information with public sector services across the globe. The resulting profile will enable standardized integration with public sector relying parties in multiple jurisdictions. The profile will be applicable to, but not exclusively targeted at, identity broker-based implementations.

The fill draft charter is available at

Feedback and additional proposers are welcome.

John Bradley
general mailing list
general <at>
Peter Williams | 22 Jul 14:58 2015

Re: [OpenID] Lots of great data about JWT and OpenID Connect adoption!


Openid connect I do see as a distinct improvement, in the generic upper layer protocol stack. It goes beyond
being an application context of layer 5, 6 and 7-baseline security protocols  cooperating with the
insecure stack to protect telematic applications. It merges the security management plane with the
comsec plane, in interesting ways.

Not sure about jwt. Apart from changing the term cert to token, not really sure why its not just the latest
encoding of x509, with profiled extensions.

I wasn't too impressed with the aws to azure aad integration, supposedly an exemplary model of American
cloud integrations. Neither the saml nor connect integrations shine.   The Google and Microsoft hookups
do look strong though (and hint at the multi cloud break through (complementing docker compusec security models)).

I'd be happier with jwt if I saw it in such as Microsoft template projects whichtraditionally teach and
liberate. So far, jwt is absent, with os/machine tokens being minted when an websites own AS handles
grants, complementing its webapi endpoint support. Perhaps things will rev, though, as folks feel
comfortable letting the AS cease to be a controlled cloud vendor, social id related concept and become a
signed blob for all occasions.

Sent from my Windows Phone

-----Original Message-----
From: "Mike Jones" <Michael.Jones <at>>
Sent: ‎7/‎21/‎2015 3:30 PM
To: "openid-specs-ab <at>" <openid-specs-ab <at>>; "Matias Woloski" <matias <at>>
Cc: "openid-connect-interop <at>" <openid-connect-interop <at>>;
"openid-code <at>" <openid-code <at>>;
"openid-general <at>" <openid-general <at>>;
"specs <at>" <specs <at>>; "board <at>" <board <at>>
Subject: [OpenID] Lots of great data about JWT and OpenID Connect adoption!

Read and check out 
Very cool!

I posted about this at and as  <at> selfissued.

                                                            -- Mike

general mailing list
general <at>
Cal Heldenbrand | 23 Jun 19:57 2015

[OpenID] Discovery Endpoint CORS support?

Hi everyone,

I noticed when reading through the OIDC core spec, Section 4 has a blurb recommending CORS header support: 

The UserInfo Endpoint SHOULD support the use of Cross Origin Resource Sharing (CORS) [CORS] and or other methods as appropriate to enable Java Script Clients to access the endpoint.

But when I look through the Discovery document, there are no mentions of CORS support.  If an OP advertises the implicit flow in the metadata, shouldn't CORS support be a requirement in the specification?  Otherwise a js client will choke on an AJAX discovery request, and the whole process is busted unless the developer manually specifies the endpoints.

I ran into this when testing the Implicit flow against Google's discovery endpoint, and started down the rabbit hole of reading.  ;-)

Thank you!


Cal Heldenbrand
   Web Operations at FBS
   Creators of flexmls® and Spark Platform
   cal <at>
general mailing list
general <at>
Peter Williams | 4 Jun 17:57 2015

[OpenID] Realty adoption

Took 5 years (from my doing a demo of Microsoft clouds gatewaying to Google's and myopenid's op) but the us realty standards group just took a decision to rip out its custom oauth profile in a webapi spec in preference to citing openid connect.

Wow. Good chunk of US GDP just endorsed openid. Someone somewhere is doing something right.

Kudos to both Microsoft azure and amazon web service for tipping the modern argument (by making it impossible to deny how easy it now is, on many platforms.) Given the full history of this little success, should also commend the google team for actual inter vendor interoperability, from the outset.

Sent from my Windows Phone
general mailing list
general <at>
Celia Brockman | 30 May 11:21 2015

[OpenID] (no subject)

I do not have any idea what your referring to

general mailing list
general <at>
Peter Williams | 27 May 22:08 2015

[OpenID] implicit and id_token

one thing I'm finding interesting is the world in which .js apps not only obtain control over the an id_token blob (via openid connect handshakes using the implicit flow) but use it (vs an access token) to talk to one or more API endpoints.

Its interesting because of semantic differences - differences from the classical oauth2 world of access tokens, of course. Certs are audience-free, of course (being intended for use by anyone, in a process of relying on digital signatures). Both Audience-free and audience-controlled id_tokens are now interesting. The combination of the audience-free cert (shared with an API endpoint using SSL client authn) and the audience-free/controlled id_token, is also very interesting combination - particularly when the cert is self-signed.

One can see a world in which consumers post the (self-signed) cert and the id_token to a discovery-site ...that allows others to discover the asserted binding between the cert and the id_token, facilitating lots more digital signature uptake. One sees how the id_token might be "signing" that document (if you recall how in ws-* land, tokens could "sign" (XML) messages).
general mailing list
general <at>
Celia Brockman | 22 May 11:00 2015

[OpenID] (no subject)

general mailing list
general <at>
Celia Brockman | 21 May 22:21 2015

[OpenID] (no subject)

general mailing list
general <at>
Andy Brown | 20 May 16:27 2015

[OpenID] Native App and web API: Is this the proper use of OpenID Connect for this use case?

I'm trying to understand how to use OpenId Connect in the following use case. Let's say we just have the
following 3 components: 

* Web app with an exposed API (Service Provider aka SP). 
* A separate authentication server (Identify Provider aka IDP) used for SSO with the above SP. 
* A native client app used by the End User. This client app uses the SP's API. 

All traffic would be over HTTPS. Here's how I envision the OpenID Connect process working: 

1. The native app would request a "token" from the SP. 
2. The SP would see the user isn't authenticated and ask for verification from the trusted IDP. 
3. After the user's credentials are provided to the IDP, the IDP would return an ID token and Access token to
the SP. 
4. The SP would verify the ID token and give the Access token to the native client app to use for all subsequent
requests to the API. 

Is this the recommended way to use OpenID Connect in this situation? Any obvious security concerns? The
only one I see is that the native client app could use the Access token to access the User Info endpoint at the

Thanks for any help! 

- Andy 
Janusz Ulanowski | 6 May 12:56 2015

[OpenID] dynamic registration

I've just read spec
And it looks like there is not option to some kind of validation like 
verify if requesting client is a owner of of keys jwks_uri
Maybe such request could be signed and then validated by auth server - 
if not then how could I verify if client is in my predefined trust group 
(similar to SAML Federaition)?

Adam Dawes | 17 Apr 09:33 2015

[OpenID] oidf-specs-risc <at>

Hi everyone,

I just wanted to announce the creation of the RISC working group mailing list (oidf-specs-risc <at> If you would like to subscribe to the list, go to:

Please note that the list is free for anyone to subscribe to but only those who have submitted their IPR agreement to the OpenID Foundation will be able to post to the list. 

There is also a RISC page on the web site. Please take a look at:

general mailing list
general <at>