Don Thibeau | 21 Mar 13:41 2014

Re: [OpenID] general Digest, Vol 85, Issue 4

For the record I do not recall the comment nor agree with the the interpretation Kaliya Hamlin attributes to me.

Don Thibeau
The OpenID Foundation

On Mar 21, 2014, at 8:00 AM, openid-general-request <at> lists.openid.net wrote:

Send general mailing list submissions to
	openid-general <at> lists.openid.net

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.openid.net/mailman/listinfo/openid-general
or, via email, send a message with subject or body 'help' to
	openid-general-request <at> lists.openid.net

You can reach the person managing the list at
	openid-general-owner <at> lists.openid.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of general digest..."

Today's Topics:

  1. Re:  [OpenID board] [Board-ec] Fwd: JTC1_N13405-Proposal for
     a liaison C between Open ID Foundation and ISO/IEC JTC1 SC27 WG5
     (Nat Sakimura)
  2.  Growing list of OpenID Connect libraries available (Mike Jones)
  3. Re:  Growing list of OpenID Connect libraries available
     (Peter Williams)
  4. Re:  [OpenID board] [Board-ec] Fwd: JTC1_N13405-Proposal	for
(Continue reading)

Mike Jones | 21 Mar 01:55 2014
Picon

[OpenID] Growing list of OpenID Connect libraries available

The list of publicly available OpenID Connect libraries is growing, with implementations available for numerous development platforms and environments, including Drupal, Java, PHP, Python, and Ruby. See the Libraries page for a list of OpenID Connect libraries, as well as libraries implementing the related JSON Web Token (JWT) and JSON Object Signing and Encryption (JOSE) specifications. These libraries make it easy to join the likewise growing list of OpenID Connect deployments.

If your library isn’t listed and you’d like it to be, please drop us a note on the code <at> openid.net mailing list or the general <at> openid.net mailing list.

Also, if you’re interested in participating in OpenID Connect interop testing, please join the openid-connect-interop <at> googlegroups.com mailing list and ask to be added to the current OpenID Connect interop.

 

                                                                -- Mike

 

P.S.  This note was also posted at http://openid.net/2014/03/20/growing-list-of-openid-connect-libraries-available/ and tweeted as <at> openid.

 

_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Mike Jones | 18 Mar 00:38 2014
Picon

[OpenID] Monday, May 5 OpenID Workshop at Yahoo! before IIW

The OpenID Foundation Workshop on Monday, May 5th before IIW has been announced.  Check it out here: http://www.eventbrite.com/e/openid-foundation-workshop-tickets-1174511997.

 

Thanks to Yahoo! for hosting.

 

                                                                -- Mike

 

_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Nat Sakimura | 9 Mar 02:15 2014
Picon

[OpenID] Fwd: Invitation to OpenID Foundation members to MIT-KIT Workshop on Private Health Data

FYI. It includes BlutButton+ in the program, which uses OpenID Connect. 

---------- Forwarded message ----------
From: Thomas Hardjono <hardjono <at> mit.edu>
Date: 2014-03-05 0:45 GMT+00:00
Subject: Invitation to OpenID Foundation members to MIT-KIT Workshop on Private Health Data
To: Nat Sakimura <n-sakimura <at> nri.co.jp>
Cc: "sakimura <at> gmail.com" <sakimura <at> gmail.com>, "agropper <at> gmail.com" <agropper <at> gmail.com>, Thomas Hardjono <hardjono <at> mit.edu>



Nat,

We would like to extend an invitation to OpenID Foundation (OIF) members to attend the coming
workshop at MIT on Private Health Data (March 28, 2014).

A key part of this workshop is understanding and promoting BlueButtonPlus, which
uses OpenID-Connect (OIC) as its core infrastructure. As such, we think this workshop
is very relevant for your members and providers who are interested in the Healthcare space.

I've included our recent announcement below.  Please feel free to forward this email to OIF members.

Thanks in advance.

Thomas Hardjono

-----------------------------------------------------------


-----Original Message-----
From: Thomas Hardjono
Sent: Wednesday, February 12, 2014 2:59 PM
To: mit-privatehealthdata <at> mit.edu
Cc: Thomas Hardjono; adrian <at> alum.mit.edu
Subject: Save the date: MIT-KIT Workshop on Private Health Data


Save the date: MIT-KIT Workshop on Private Health Data

We are pleased to invite you to the MIT-KIT Workshop on Private Health Data to be held on March 28, 2014 at the MIT Media Lab.

This one-day meeting will explore next-generation services infrastructure for the sharing of patient data and other resources in the healthcare space. We will pay particular attention to open issues in digital identity, patient matching, and authorization management that stand in the way of large-scale interoperability and predictive analytics. Our program will focus on emerging Web-scale technologies as applied to health information sharing and will be heavily weighted toward group discussion among our expert participants.

An agenda will follow in the coming days. The program will begin with a review of open issues, followed by relevant Web practices outside of healthcare, and end with healthcare-specific profiles of generic practices.

We hope you will come.  Please register below and forward this email to colleagues you’d like to have attend as well.

Information Page, Agenda & Registration (free):
http://kit.mit.edu/events/mit-kit-workshop-private-health-data



Thomas Hardjono & Adrian Gropper








______________________________________________
Thomas Hardjono, PhD.
Executive Director
MIT Consortium for Kerberos & Internet Trust

Massachusetts Institute of Technology
77 Massachusetts Avenue W92-152
Cambridge, MA 02139, USA

e: hardjono[at]mit.edu    m: +1 781-729-9559
______________________________________________




--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Mike Jones | 26 Feb 15:31 2014
Picon

[OpenID] The OpenID Foundation Launches the OpenID Connect Standard

See http://openid.net/2014/02/26/the-openid-foundation-launches-the-openid-connect-standard/ and the tweet at <at> openid.

 

This was also already favorably covered by TechCrunch:  http://techcrunch.com/2014/02/26/openid-foundation-launches-openid-connect-identity-protocol-with-support-from-google-microsoft-others/.

 

                                                            Cheers,

                                                            -- Mike

 

_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Manger, James | 26 Feb 02:28 2014

[OpenID] Changing identity provider (OP)

Hi OpenID community,

Is there any work going on about how users can change their OpenID Connect provider (OP) while keeping
access to their accounts at RPs? With or without explicitly engaging every site (RP) the user connects to?

With OpenID 2.0 a user cannot change their identifier (OpenID URI), but they can change the OP it points to.
I'm not sure how well that works in practise and at scale, nor how it works with the added privacy of pairwise
(per RP) pseudonyms.
With OpenID Connect a user’s stable identifier is an issuer/subject (iss/sub) pair. A user cannot
change OP as that will change iss so RPs will no longer recognize the user.

One solution is for a user to visit every RP: within one session login via their old OP and login via their new
OP so the RP can link the two iss/sub pairs. This requires RPs to explicitly support such an interaction. Is
there work on standardizing how this could work at RPs (perhaps even automatically)? It probably
requires almost all RPs to support this approach for it to be viable for users.

--
James Manger

_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Mike Jones | 20 Feb 20:01 2014
Picon

[OpenID] Please participate in the vote to approve final OpenID Connect specifications

If you haven’t already participated in the vote to approve final OpenID Connect specifications, please do so at https://openid.net/foundation/members/polls/80.  The vote will close at Noon Pacific Time on Tuesday, February 25th.

 

If you’re not already a member, or if your membership has expired, please consider joining to participate in the approval vote. Information on joining the OpenID Foundation can be found at https://openid.net/foundation/members/registration.

 

Thanks,

Michael B. Jones

OpenID Foundation Secretary

_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Mike Jones | 11 Feb 19:45 2014
Picon

[OpenID] Vote for Final OpenID Connect Specifications and Implementer’s Drafts is Open

The opening of the vote to approve four final OpenID Connect specifications and two Implementer’s Drafts has been announced at http://openid.net/2014/02/11/vote-for-final-openid-connect-specifications-and-implementers-drafts-is-open/.

 

Please vote now at https://openid.net/foundation/members/polls/80.

 

-- Michael B. Jones – OpenID Foundation Secretary

_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Peter Williams | 24 Jan 22:53 2014
Picon

[OpenID] Fw: oauth assertion bearer grant - motivation?

Looking more at the cited openid connect case, I recognize now that we are already doing the same kind of thing as Google, apparently. That is, whereas in Google and an idtoken is apparently issued as a bearer token for OTHER audiences than the requesting party, we just happened to have the issuer of the saml bearer blob perform that role, as it nominally “accompanies” the id_token in the JSON response that retains the AS audience in our world. 

The saml bearer token is then swapped at the MicrosoftOnline STS to get an access token for an the simple federation-secured protocols exposed by the public Office 365 APIs. As you say, this all requires that the websso client built into a pure OAUTH or openid connect authorization endpoint should request of the websso IDP that it issue a user--subject assertion with an audience OTHER than the identity of the AS (or in our case, with multiple audiences, the AS and the MicrosoftOnline audience). This also needs to have subject formats suitable for the STS (which are UPNs, and name record persistentIDs, in windows directory land).

Or so we thought. It turns out that the MicrosoftOnline STS is fussy about multiple audiences in the token bearer, and objects to a multiple. So, we played with the above ideas, in ways that are a bit proprietary but entirely standard in terms of using claims/libraries, so we could have multiple saml2 websso tokens coming back, one per audience.

This turned out to have a nice side effect, as now we can request asymmetric keyed tokens for use within the (non Office365) AS-client world. That is, the OAUTH client eventually consuming the AS’s token endpoint uses the saml bearer grant that converts the AS-audience’d SAML blob to JWTs. This was proprietary, but evidently, I can use the “salesforce” standard for that, now. Though, perhaps not …since we use asymmetric keyed bearer grants so that the fabric ends up with what is effectively a saml-blob-format self-signed user cert (in XML format, now).

This hybrid world is working VERY nicely. Asymmetric saml is even allowing “certs” to make a come back, now in a new blob format. We are using them for trust management between tenants of the SAAS space, rather than use directory forests and Kerberos trusts. SOME of still believe… in PKI theory for inter-domain management (when done professionally)

Ok that's it from me for a few months, I think.

Sent from Surface Pro

From: peter Msn
Sent: ‎Thursday‎, ‎January‎ ‎23‎, ‎2014 ‎8‎:‎03‎ ‎PM
To: John Bradley
Cc: openid-general <at> lists.openid.net

So lets summarize.

Opened connect, and bearer auth from saml blobs to jwt blogs, are about millions of (X.500 style) security management domains setting up mutual trust relationship, having a cloud fabric (read X.500 chaining directory agent) enforce and enact lots of reliance policies established by namespace, and otherwise swapping id tokens for API guard-passing tokens, with the possibility that a id_token issued by IDP.X is recognized by the token swappers of another cloud, associated with IDP.Y, where X and Y have some policy agreements.

Ok. I get openid connect now. There are several layers of trust relationships, meta-trust relationship, and meta-meta trust (etc), that account for when one IDP relies on another for some or other purpose, as above.

Still think cross-certs were better suited for all this, particularly with the flexible algebra of policy matching built into X.509 v3, but that's a lost battle.

Thanks for the help. Reasons to at least partially adopt openid connect were made obvious. One sees the writing on the wall, now (and it is good).

Sent from Surface Pro

From: John Bradley
Sent: ‎Thursday‎, ‎January‎ ‎23‎, ‎2014 ‎3‎:‎30‎ ‎PM
To: peter Msn
Cc: openid-general <at> lists.openid.net

The Bearer grant allows the SAML assertion to be passed directly to the token endpoint as the grant cutting out the Authorization web redirect and return of the code.

This is a optimization useful where the AS doesn't need to collect consent from the user.   However the SAML IdP and the AS need to agree on how the scopes to be granted are represented in the assertion.

In Connect it is possible to ask for a id_token with a 3rd party as the audience.  (Google is doing that with the play store)  That id_token can be used in the JWT bearer grant http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer to get a access token for a 3rd party API.  

So a native app could do Connect authentication hypothetically Google then use it's refresh token to ask for a id_token with SalesForce or Microsoft as the audience and then use the  id_token as the JWT grant to get a access token for SF or Azure as examples.   This is more likely than Google being able to issue access tokens for those 3rd party API directly.

Yes you can have the app redirect to the AS and the AS do SSO  Connect or SAML to a 3rd party IdP and that works but may disclose more information to the AS than is actually required.
So it is an alternate way to cross security boundaries.

John B.

On Jan 23, 2014, at 6:24 PM, Peter Williams <home_pw <at> msn.com> wrote:


Say just a little more, since this swapping of “enterprise” issued (saml blob) tokens  all overlaps with openid connect in my mind - where the latter has different type of jwt: one for passing (classical oauth-powered) access guards at webapis, and those one's  delivering identity claims and attributes from a backroom directory.
 
Ive built and deployed a websso and oauth hybrid. Invoking authorization via a  (embedded)Brower requires one to conclude websso, with a wsfedp idp, that mints saml tokens. Said token opens the consent gate, that controls minting of oath grants. Subsequently, Use of token endpoint, citing a one time code or other proof token, returns a Json object with one or more jwts, and the websso bearer token, and an microsoftonline sts-issued(swapped from bearer) token usable at office365 wstrust/wssecurity/wssecureconversation guarded APIs.

thick clients, phone apps, tablet apps and websites acting as agents are all happy with all that. And it fits with today's devices and middleware now (finally) adopted by us realty, and its 300 vendors.

What the oath bearer grant has done is confuse me more, particularly in understanding how the scopes from grants are aggregated, and WHY. I already don't really get how I'm supposed * to use* different jwts, in the openid connect profile, for “radically innovative” use cases that align with how folks are assuming enterprise, and social, and APIs, and mixed app\browser apps are all supposed to work, next generation.

Prehaps a call for a blog post or two?

Sent from Surface Pro

From: John Bradley
Sent: ‎Thursday‎, ‎January‎ ‎23‎, ‎2014 ‎11‎:‎34‎ ‎AM
To: peter Msn
Cc: openid-general <at> lists.openid.net

This is the openID list and not a OAuth list, but I will attempt an answer.


Basically it is a way to do token translation.   In some cases when interfacing with Enterprise systems getting them to issue a SAML token may be easier the simplest thing to do.

The resource server (RS) however likely only understands a single access token form. GUID or JWT for the most part.   The assertion profiles let the client translate a JWT or SAML assertion into a OAuth access token.

This can be quite useful in crossing security domains where the AS is relying on a 3rd party to authenticate the user.   The AS could redirect to a SAML IDP using websso but on mobile devices that might not be optimal.  

The scopes associated with the access token can be a subset of the ones granted by the SAML assertion.   In some cases with multiple endpoints you may want to down scope the access token.

The biggest user of this flow is SalesForce as far as I know.

John B.

On Jan 23, 2014, at 3:46 PM, Peter Williams <home_pw <at> msn.com> wrote:

It took me a while (and several years of lateness) to comprehend just what kind of world the classical oauth grants were designed for.  One advantage of being late to the party was that I tended to get better variants, such as a grant returning a JWT bearing attributes rather than using grants that returnee guids as tokens - that had to be subsequently resolved.

So what is the “use case” of the saml2 bearer assertion grant?

I makes perfect sense that someone with a bearer assertion might swap it for a JWT, for use at APIs. And it makes perfect sense that such a saml assertion plays much the same role as a does possession of an optional renewal-token - the one native to an OAUTH handshake.

But I don't see what the “generation changing” motivation is for the scopes - that the access token returns all scopes for which tokens (with renewals) have previous been issued.

So what is the 'context’ of control being enabled here? What thing is this scope-aggregation feature working for?


Sent from Surface Pro

_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general

Attachment (ATT00001): application/octet-stream, 211 bytes
_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Peter Williams | 23 Jan 19:46 2014
Picon

[OpenID] oauth assertion bearer grant - motivation?

It took me a while (and several years of lateness) to comprehend just what kind of world the classical oauth grants were designed for.  One advantage of being late to the party was that I tended to get better variants, such as a grant returning a JWT bearing attributes rather than using grants that returnee guids as tokens - that had to be subsequently resolved.

So what is the “use case” of the saml2 bearer assertion grant?

I makes perfect sense that someone with a bearer assertion might swap it for a JWT, for use at APIs. And it makes perfect sense that such a saml assertion plays much the same role as a does possession of an optional renewal-token - the one native to an OAUTH handshake.

But I don't see what the “generation changing” motivation is for the scopes - that the access token returns all scopes for which tokens (with renewals) have previous been issued.

So what is the 'context’ of control being enabled here? What thing is this scope-aggregation feature working for?


Sent from Surface Pro

_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Peter Williams | 18 Oct 22:49 2013
Picon

[OpenID] openid connect as metadata management (windows)

I have to admit I deliberately avoided the oauth movement - when it was about stuffing a third-parties frame into a facebook or google controlled page. This was far too webby (and likely to be transitory).
 
I have to admit I deliberately avoided the oauth movement - when it was about putting apps on devices, controlled by app stores. This was far too much about app stores and flogging dollar apps to teenagers.
 
I have to admit I deliberately avoided the oauth movement - when it was about having native app code get tokens to consume API, limited to a given users' entity scope. This was interesting, but too immature - since oauth control processes used by vendor A's API didn't work with vendor B's API. Far too much like the IM wars between yahoo, AOL, Google, etc
 
I totally get - however - the "novelty" of Microsoft's application of oauth2 (and "openid connect"?) for automating the process of adding an RP site to an IDPs relying party list (known as adding an "SP-connection" in pingfederate land, or a "relying-party trust" in Windows ADFS land). This seems to be a leap forward, in the TRADITIONAL world of websso.  It automates some of the tedious federation-metadata processes, typically done offline by admins. And it does so in a manner that is ALSO about device control - giving the "controlling IDP" some power over the devices ultimately used by user of the RP app/webapp, ... logically to remotely wipe them...whenever the IDP want (or some govt issues a secret order).
 
Ok. I get it.
 
Federation metadata automation, and control projection - layered on top of  private(*) trust graph formation.
 
(*) private as in not-public. "community of interest", in other words.
 
 
 
_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general

Gmane