Victor Ake | 19 Aug 08:49 2014

[OpenID] List of products supporting OpenID Connect

Hello,
I would like to add to the list of products supporting OpenID Connect 
the following products:

Name of the product: OpenAM (Open Access Manager)
Link: http://www.forgerock.com/products/open-identity-stack/openam/
Description: ForgeRock OpenAM is the all-in-one, highly scalable access 
management solution that supports OpenID Connect Identity Provider and 
Relying Party.
Binary License: Commercial
Open Source License: CDDL
Relying Party Support: Yes
Identity Provider Support: Yes
Target Environment: Multi platform, serving mobile, desktop and IoT

OpenIG (Open Identity Gateway)
Link: http://www.forgerock.com/products/open-identity-stack/openig/
Description: ForgeRock OpenIG is an application and API gateway that 
leverages SAML 2.0, OpenAM SSO, OAuth 2.0 and OpenID Connect. It 
supports OpenID Connect Relying Party.
Binary License: Commercial
Open Source License: CDDL
Relying Party Support: Yes
Identity Provider Support: No
Target Environment: Multi platform, serving mobile, tablet, desktop and IoT

Please let me know if you have any questions.

   Thanks,

(Continue reading)

Celia Brockman | 19 Jun 12:54 2014
Picon

[OpenID] (no subject)


_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Peter Williams | 11 May 21:20 2014
Picon

Re: [OpenID] understanding where openid foundation is going, on advanced controls

generally speaking, Ive been following how microsoft cloud and directory is rolling out its first incarnation of openid connect for commodity developers to use. And its very simple (with openid connect being merely one of several protocols that come together as a websso/webapi family). Im hardly smart, and I CAN get it (in that form).

There,  openid connect is presented as little more than oauth2 with an id-token (assuming that the access token might be encrypted one day, denying its repurposing as an id token with claims for UIs). The openid connect world shares some control plane material with the non openid-connect profiles of the family (which includes ws-fedp, and non-openid connect profiles of oauth2). This uses old SAML-proof token features like scopes and audiences and claim names standardization. These, whether in the openid connect compatability modes or not, can be orchestrated so the control and management does the technically-govern multi-server interactions - as a distributed/partitioned TCB (NCSC Red Book model for secure networking).

If it helps, I for one cannot relate much of what I read in the standard to what I see being practiced. It all feels somewhat like the PKIX spec, that took 100 pages to define what certs do (which only required 15 ISO pages in 1988, and 30 pages in 2000). The number of folks using the advanced profiles of PKIX must be about 0.000001% percent of the internet, with the 80% using the bottom set of features that have not really changed much in 20 years.

Now, you might come back at me and say: this is NOT for general internet apps building. This is REALLY all for telcos, and the world like Neustar run in which huge numbers of management servers control the security policy that govern interworking, roaming of users in such as GSM. And thus THAT is where openid foundation is REALLY focused (and not on the likes of me, in the traditional web world).

have I captured the right way to think - about where emphasis of all the work is targeted?


From: John Bradley
Sent: ‎Sunday‎, ‎May‎ ‎11‎, ‎2014 ‎11‎:‎06‎ ‎AM
To: Takahiko Kawasaki
Cc: openid-general <at> lists.openid.net

This list is for general information about openID.

The correct place to discuss deployment and interop issues and questions is OpenID Connect Interop
That group/list has no IPR restrictions.

For discussing errata or other issues with the Connect specifications the list is http://lists.openid.net/mailman/listinfo/openid-specs-ab.
You must sign a non assert IPR agreement to contribute to the specification, as all the other WG participants have.

The Connect WG page lists the links and other useful information http://openid.net/connect/

The version of Dynamic Client registration being developed by the OAuth WG in the IETF based on the Connect specification can be discussed at:

To your question Registration's application type is not the same as RFC 6749 Sec 2.1 Client Types.

It is dynamic registration itself that allows a native app to be confidential so that section of RFC 6749 may be changed after the IETF approves dynamic client registration.

That section also states

A client may be implemented as a distributed set of components, each with a different client type and security context (e.g., a distributed client with both a confidential server-based component and a public browser-based component).

Connect supports this with the hybrid response types.

A Web application with a single client_id  may contain both a public component and a confidential component.  

The element response_type determines the flows the client can preform.

The default for that is the client can only preform the code flow and must use a client credential to authenticate itself to the token endpoint.

The response types are a finer grained and imply public and private for the hybrid components.

What is not possible without extending dynamic client registration are public clients that use a code grant_type.
One of the main reasons for dynamic client registration is to eliminate the need for an AS to support public clients using the code grant_type.

In any event we can continue this on one of the other lists.

John B.

On May 11, 2014, at 6:56 PM, Takahiko Kawasaki <daru.tk <at> gmail.com> wrote:

Thank you for your comment.

If both native clients and web clients can be public or confidential,
application_type which is described in Client Metadata section of
OpenID Connect Dynamic Client Registration 1.0 is DIFFERENT from the
client type described in RFC 6749.

Considering the following two points:

  (1) RFC 6749 (OAuth 2.0) requires a client type to be registered.
      (RFC 6749, 2. Client Registration)

  (2) OpenID Connect Relying Party is a kind of OAuth 2.0 client app.
      (OpenID Connect Core 1.0, 1.2. Terminology)

there should be a client metadata entry to specify a client type (e.g.
client_type), and it should be treated separately from application_type.

Information about Client Type (not Application Type) is really needed
to implement OAuth 2.0 authorization server correctly. Especially it
is needed to determine (1) whether client authentication is required
at the token endpoint (3.2.1. Client Authentication) and (2) whether
registration of redirect URIs can be omitted (3.1.2.2. Registration
Requirements).

Without a client metadata entry to specify a client type, the default
value of client type cannot help but be left to implementations of
OpenID Connect Dynamic Client Registration 1.0.

IMHO, if such an entry (e.g. client_type) should be added, 'public'
would be appropriate as the default value because 'client_secret' in
Client Registration Response is OPTIONAL.

--
Best Regards,
Takahiko Kawasaki




2014-05-11 5:54 GMT+09:00 John Bradley <ve7jtb <at> ve7jtb.com>:
Native clients may also be confidential if they register a unique client_id and have a secret that is provisioned in registration or out of band in some way.

Web includes both confidential and public types of clients.

Client type web or native came from a number of IdP like Google who do not allow the same client_id to be used across different types of clients.

The type of client restricts the type of redirect_uri that is allowed to be registered.

All clients must register full redirect URI and the Authorization server must match the registered redirect_uri with the one in the request.

The recent covert redirect furor and the consequences of Facebook not requiring it should go some way to explaining why registering redirect_uri is important.

One reason for not allowing native_apps and back end Web servers to share a client_id is privacy.   A user granting a app on there phone access to a API is not the same as
granting a Web site access, and a user discovering that consenting to one automatically consented to the other may not be taken well.

The reason for separating the two types of clients is both good security and good privacy policy.

John B.


On May 10, 2014, at 12:02 PM, Takahiko Kawasaki <daru.tk <at> gmail.com> wrote:

> If "Native Clients" in "OpenID Connect Dynamic Client Registration
> 1.0, 2. Client Metadata" means "native application" in "RFC 6749
> (OAuth 2.0), 2.1 Client Types" (yes it apparently does), "Native
> Clients" are always 'public' clients.
>
> If "Web Clients" in "OpenID Connect Dynamic Client Registration 1.0,
> 2. Client Metadata" means "web application" in "RFC 6749 (OAuth 2.0),
> 2.1 Client Types" but does not include "user-agent-based application",
> "Web Clients" are always 'confidential' clients.
>
> Using the above interpretation, application_type=native and
> application_type=web correspond to 'public' and 'confidential',
> respectively.
>
> However, the requirement of application_type:
>
>    Web Clients using the OAuth Implicit Grant Type MUST only
>    register URLs using the https scheme as redirect_uris; they
>    MUST NOT use localhost as the hostname. Native Clients MUST
>    only register redirect_uris using custom URI schemes or URLs
>    using the http: scheme with localhost as the hostname.
>
> is irrelevant to whether or not clients are "capable of maintaining
> the confidentiality of their credentials" (from RFC 6749). In other
> words, redirect URIs are irrelevant to how to authentication clients.
> Therefore, it sounds to me that Application Type and Client Type are
> different concepts.
>
> It is weird that all "OAuth 2.0 clients" must comply with either of
> the 'redirect_uris' requirements (one is for Web Clients and the
> other is for Native Clients), so probably it is inappropriate that
> 'web' is used as the default value when application_type is omitted.
> IMHO, neither of 'native' nor 'web' should be assumed when
> application_type is omitted. But, I may be missing something. Is
> there any reason to impose the 'redirect_uris' requirements on all
> "OpenID Connect clients"?
>
> Anyway, my conclusion is that Application Type and Client Type are
> different. And I hope that client_type (public or confidential) is
> added to the list of Client Metadata and that neither of 'native'
> nor 'web' is used as the default value when application_type is not
> contained in client registration requests.
>
> --
> Best Regards,
> Takahiko Kawasaki
>
>
> 2014-05-10 10:29 GMT+09:00 Takahiko Kawasaki <daru.tk <at> gmail.com>:
>> Hello,
>>
>> I'm wondering whether this is the right place to ask my question.
>> If not, please tell me so.
>>
>> I posted a question to StackOverflow, but no answer yet.
>>
>>  http://stackoverflow.com/q/23557801/1174054
>>
>> My question is "Does Application Type (OpenID Connect) correspond to
>> Client Type (OAuth 2.0)?" Could anyone give me an answer please?
>> Below is the detail of the question.
>>
>> "OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata"
>> has an entry named application_type, whose defined values are
>> 'native' and 'web'.
>>
>>  --- Excerpt from OpenID Connect Dynamic Client Registration ------
>>  application_type
>>    OPTIONAL. Kind of the application. The default, if omitted, is
>>    web. The defined values are native or web. Web Clients using the
>>    OAuth Implicit Grant Type MUST only register URLs using the
>>    https scheme as redirect_uris; they MUST NOT use localhost as
>>    the hostname. Native Clients MUST only register redirect_uris
>>    using custom URI schemes or URLs using the http: scheme with
>>    localhost as the hostname. Authorization Servers MAY place
>>    additional constraints on Native Clients. Authorization Servers
>>    MAY reject Redirection URI values using the http scheme, other
>>    than the localhost case for Native Clients. The Authorization
>>    Server MUST verify that all the registered redirect_uris conform
>>    to these constraints. This prevents sharing a Client ID across
>>    different types of Clients.
>>  ------------------------------------------------------------------
>>
>> Do these defined values correspond to 'public' and 'confidential'
>> described in "RFC 6749 (OAuth 2.0), 2.1. Client Types"?
>>
>>  --- Excerpt from RFC 6749 (OAuth 2.0) ----------------------------
>>  OAuth defines two client types, based on their ability to
>>  authenticate securely with the authorization server (i.e., ability
>>  to maintain the confidentiality of their client credentials):
>>
>>    confidential
>>      Clients capable of maintaining the confidentiality of their
>>      credentials (e.g., client implemented on a secure server with
>>      restricted access to the client credentials), or capable of
>>      secure client authentication using other means.
>>
>>    public
>>      Clients incapable of maintaining the confidentiality of their
>>      credentials (e.g., clients executing on the device used by the
>>      resource owner, such as an installed native application or a
>>      web browser-based application), and incapable of secure client
>>      authentication via any other means.
>>  ------------------------------------------------------------------
>>
>> If not, why doesn't the specification (OpenID Connect Dynamic Client
>> Registration 1.0) have an entry to specify a client type? Is there
>> any way to specify a client type (public or confidential) at the
>> client registration endpoint?
>>
>>
>> --
>> Best Regards,
>> Takahiko Kawasaki
> _______________________________________________
> general mailing list
> general <at> lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general



_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Takahiko Kawasaki | 10 May 03:29 2014
Picon

[OpenID] Does Application Type correspond to Client Type?

Hello,

I'm wondering whether this is the right place to ask my question.
If not, please tell me so.

I posted a question to StackOverflow, but no answer yet.

  http://stackoverflow.com/q/23557801/1174054

My question is "Does Application Type (OpenID Connect) correspond to
Client Type (OAuth 2.0)?" Could anyone give me an answer please?
Below is the detail of the question.

"OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata"
has an entry named application_type, whose defined values are
'native' and 'web'.

  --- Excerpt from OpenID Connect Dynamic Client Registration ------
  application_type
    OPTIONAL. Kind of the application. The default, if omitted, is
    web. The defined values are native or web. Web Clients using the
    OAuth Implicit Grant Type MUST only register URLs using the
    https scheme as redirect_uris; they MUST NOT use localhost as
    the hostname. Native Clients MUST only register redirect_uris
    using custom URI schemes or URLs using the http: scheme with
    localhost as the hostname. Authorization Servers MAY place
    additional constraints on Native Clients. Authorization Servers
    MAY reject Redirection URI values using the http scheme, other
    than the localhost case for Native Clients. The Authorization
    Server MUST verify that all the registered redirect_uris conform
    to these constraints. This prevents sharing a Client ID across
    different types of Clients.
  ------------------------------------------------------------------

Do these defined values correspond to 'public' and 'confidential'
described in "RFC 6749 (OAuth 2.0), 2.1. Client Types"?

  --- Excerpt from RFC 6749 (OAuth 2.0) ----------------------------
  OAuth defines two client types, based on their ability to
  authenticate securely with the authorization server (i.e., ability
  to maintain the confidentiality of their client credentials):

    confidential
      Clients capable of maintaining the confidentiality of their
      credentials (e.g., client implemented on a secure server with
      restricted access to the client credentials), or capable of
      secure client authentication using other means.

    public
      Clients incapable of maintaining the confidentiality of their
      credentials (e.g., clients executing on the device used by the
      resource owner, such as an installed native application or a
      web browser-based application), and incapable of secure client
      authentication via any other means.
  ------------------------------------------------------------------

If not, why doesn't the specification (OpenID Connect Dynamic Client
Registration 1.0) have an entry to specify a client type? Is there
any way to specify a client type (public or confidential) at the
client registration endpoint?

--
Best Regards,
Takahiko Kawasaki
Mike Jones | 8 May 02:25 2014
Picon

[OpenID] FW: May 5, 2014 OpenID Foundation Workshop Notes

 

 

From: Mike Jones
Sent: Wednesday, May 07, 2014 5:24 PM
To: Bill Mills; Dylan Casey; Don Thibeau; Justin P. Richer; John Fontana; Erik Wahlström; George Fletcher; John Bradley; Sumana Annam; Shraddha Ladda; Bill Welch; Tarun Rochiramani; Emily Xu; Mark Dobrinic; Sascha Preibisch; Matthew Berry; Bryant Cutler; Shon Shah; Per Hägerö; Roland Hedberg; Steve Olshansky; Brian Campbell; Jin Wen; Alex Chong; Abhijit Solanki; Vivek Biswas; Dipankar Sarkar; Michael Schwartz; Ashish Jain; Dale Olds; Hannes Tschofenig; Moorthi PV; Naveen Agarwal; Breno de Medeiros; Michael Engan; Morteza Ansari; Jack Greenberg; Adam Dawes; Pamela Dingle; Nathan Dors; Paul Madsen; Bjorn Hjelm
Subject: May 5, 2014 OpenID Foundation Workshop Notes

 

Attendees:

 

Bill Bills, Yahoo!

Dylan Casey, Yahoo!

Don Thibeau, OpenID Foundation

Mike Jones, Microsoft

Justin Richer, MITRE

John Fontana, Ping Identity

Erik Wahlström, Nexus

George Fletcher, AOL

John Bradley, Ping Identity

Sumana Annam, Centrify

Shraddha Ladda, VMWare

Bill Welch, VMWare

Tarun Rochiramani, VMWare

Emily Xu, VMWare

Mark Dobrinic, Cozmanova

Sascha Preibisch, CA Technologies

Matthew Berry, Amazon Web Services

Bryant Cutler, Amazon Web Services

Shon Shah, Amazon Web Services

Per Hägerö, Nexus

Roland Hedberg, Umeå University

Steve Olshansky, Internet Society

Brian Campbell, Ping Identity

Jin Wen, McKesson

Alex Chong, Verizon

Abhijit Solanki, Symantec

Vivek Biswas, Cisco

Dipankar Sarkar, Cisco

Mike Schwartz, Gluu

Ashish Jain, VMWare

Dale Olds, VMWare

Hannes Tschofenig, ARM

Moorthi PV, Indo-Mars

Naveen Agarwal, Google

Breno de Medeiros, Google

Michael Engan, T-Mobile

Morteza Ansari, Cisco

Jack Greenberg, Google

Adam Dawes, Google

Pamela Dingle, Ping Identity

Nathan Dawes, University of Washington

Paul Madsen, Ping Identity

Bjorn Hjelm, Verizon

 

The following presentations were given during the May 5, 2014 OpenID Workshop:

 

The reports of a purported "Covert Redirect" vulnerability were also discussed.  Participants were directed to the responses by Symantec and John Fontana.

 

 

The notes are also posted at http://wiki.openid.net/w/page/80030213/May%205%2C%202014%20OpenID%20Workshop.

 

 

_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
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
     a liaison C between Open ID Foundation and ISO/IEC JTC1 SC27 WG5
     (John Bradley)
  5. Re:  [OpenID board] [Board-ec] Fwd: JTC1_N13405-Proposal for
     a liaison C between Open ID Foundation and ISO/IEC JTC1 SC27 WG5
     (Torsten Lodderstedt)

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

Message: 1
Date: Fri, 21 Mar 2014 09:47:22 +0900
From: Nat Sakimura <sakimura <at> gmail.com>
To: Kaliya Identity Woman <identitywoman <at> gmail.com>
Cc: "openid-general <at> lists.openid.net"
	<openid-general <at> lists.openid.net>
Subject: Re: [OpenID] [OpenID board] [Board-ec] Fwd:
	JTC1_N13405-Proposal for a liaison C between Open ID Foundation and
	ISO/IEC JTC1 SC27 WG5
Message-ID:
	<CABzCy2DMNDdpokEiG9Bu9YXyAwXi4MXit4vb5JYd4Cixa9LKRA <at> mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Removing: board <at> openid.net and board-ec <at> openid.net from the Cc list and
adding openid-general since this is more of a community question and not
the board discussion.

2014-03-21 7:31 GMT+09:00 Kaliya Identity Woman <identitywoman <at> gmail.com>:

> I asked Don last time we were in person if the GSMA in its use/adoption of
> OpenID was going to enable people to easily have more then one profile on
> their device. He basically said they hadn't thought of it and in effect
> said "nope".

Actually, this is not true. Many telcos are perfectly willing to give
ability to the consumers multiple "identities".
The credential being SIM based and the support of multiple
"identity/partial identity/paersona" is an orthogonal thing.
Perhaps Torsten can chime in here as well.

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
 <at> _nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20140321/7546fd9c/attachment-0001.html>

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

Message: 2
Date: Fri, 21 Mar 2014 00:55:03 +0000
From: Mike Jones <Michael.Jones <at> microsoft.com>
To: "code <at> openid.net" <code <at> openid.net>, "general <at> openid.net"
	<general <at> openid.net>
Subject: [OpenID] Growing list of OpenID Connect libraries available
Message-ID:
	<4E1F6AAD24975D4BA5B16804296739439A101D60 <at> TK5EX14MBXC286.redmond.corp.microsoft.com>
	
Content-Type: text/plain; charset="us-ascii"

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<http://openid.net/developers/libraries/> page for a list of OpenID
Connect<http://openid.net/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<http://lists.openid.net/mailman/listinfo/openid-code> or the general <at> openid.net mailing list<http://lists.openid.net/mailman/listinfo/openid-general>.

Also, if you're interested in participating in OpenID Connect interop testing, please join the
openid-connect-interop <at> googlegroups.com mailing
list<http://groups.google.com/group/openid-connect-interop> and ask to be added to the current
OpenID Connect interop<http://osis.idcommons.net/wiki/OC5:OpenID_Connect_Interop_5>.

                                                               -- 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20140321/40e3a12e/attachment-0001.html>

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

Message: 3
Date: Fri, 21 Mar 2014 01:00:15 +0000
From: Peter Williams <home_pw <at> msn.com>
To: "=?utf-8?Q?general <at> openid.net?=" <general <at> openid.net>
Subject: Re: [OpenID] Growing list of OpenID Connect libraries
	available
Message-ID: <SNT405-EAS299C9306F05BCC3C806F9992790 <at> phx.gbl>
Content-Type: text/plain; charset="utf-8"

I'll give a small challenge and feedback for developers - addressing a challenge I see. The challenge is due
to the ?ever changing? websso world.

We have a joomla deployment, that REALLY exploits websso. From claims in the inbound assertion, all sorts
of application roles drive menus, drive profiles, drive link visibility, drive page embedding, (etc
etc). I think this was known, in the last round of fancy marketing, as claims driven apps (or something).
Identity metasystem, or something. Hey, it may even have been ?user centric?.

I'd love to move FROM current ws-fedp plugin (that cost a $1000 to do, when given to the right person) to
openid connect. Perhaps, I could find another $1000?

Now, I'm not known as the smartest key on the chain, and still see the world in simple terms. I'm happy for such
as the Microsoft openid connect solution (in the cloud) to invoke websso for me (in response to an openid
connect request - for an id_token). Sure, I could make Joomla call openid connect (to invoke websso). And,
obviously, a token translation occurs on the return leg, moving values from the ws-fedp-delivered
assertion (from the websso step) to the oauth authorization process (that delivers a nice JWT to me, with
some of the ?claims? from the websso step).

If I cannot get the claims I currently get (from direct access to websso), I cannot move to openid connect
(which gives me ONLY indirect access to websso, and claims handover that is decided by others). Which
makes openid connect MIGRATION hard ).

Yes - you might way - your silly implementation, Peter,  doesn't fit the "Intended pattern?. Which is, of
course, your fault (for buying into last years marketing, around claims, if not user centric consent and
control). Rebuild it all (and adopt the ?right pattern?!!). And, of course that will happen (when one just
dumps - rather than revises - the ?old? stuff) 

Of course, that is not reality (as code and patterns marketed and adopted only 2 years ago have a multiple
year lifetime, down here on main street. Not all of us are billion dollar companies (with payoffs from
natsec agencies or potential federal cloud contracts for 100,000 tenants?).

Just some feedback on ?adoption?, in that 80% of the market that is ?bound up? in legacy cost economics. Even
legacy of ? 2 years ago.

Having ?groked? openid connect (thanks to superb Microsoft cloud-based delivery of it ), I'm for it (now I
get it). Now reality sets in. Change is hampered by the ?advanced? stuff done , ahem, 2 years ago - whose very
PATTERN is already considered ?legacy?. 

Hopefully this spurs the next generation of developers - who know a bit that large market of 
?legacy migration? (from claims to connect?)

From: Mike Jones
Sent: ?Thursday?, ?March? ?20?, ?2014 ?5?:?55? ?PM
To: code <at> openid.net, general <at> openid.net

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20140321/25559c72/attachment-0001.html>
-------------- next part --------------
_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general

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

Message: 4
Date: Fri, 21 Mar 2014 00:46:24 -0300
From: John Bradley <ve7jtb <at> ve7jtb.com>
To: Nat Sakimura <sakimura <at> gmail.com>
Cc: "openid-general <at> lists.openid.net"
	<openid-general <at> lists.openid.net>
Subject: Re: [OpenID] [OpenID board] [Board-ec] Fwd:
	JTC1_N13405-Proposal	for a liaison C between Open ID Foundation and
	ISO/IEC JTC1 SC27 WG5
Message-ID: <FE2669E9-B157-497A-8C92-EE9EEB709A6C <at> ve7jtb.com>
Content-Type: text/plain; charset="iso-8859-1"

In discussions I have had with Mobile operators privacy has been a concern, though that may be influenced by
many of them being in Europe and having to conform to much stricter privacy laws than in the US.

The connect profile is intended to create a common set of features and possibly a single registration point
to make it possible for RP to deal with potentially 800 IdP given that the internet is global.

I think many people will agree that creating a common identity layer rather than regional ones is a good thing.

Asking about persona on the device may have confused the issue.  It would surprise me if multiple persona
including non corralatable ones are not supported for asserting to RP.

That is different from multiple persona on the device being used for authentication to the MNO as the IdP.  

In developing the profile support for pairwise identifiers will need to be sorted out.  They have privacy
benefits as long as you are not handing out other corralatable attributes.

One value add the MNO have is that they can provide proofed attributes with the users consent.   In the
multiple persona case there may be legal restrictions on them providing attributes they know are not
true.  So outside of the technical profile that we are developing there may be policy issues that the
operators need to deal with.

One side benefit of this is if the we get RP into the ecosystem this way and can move them to a world where they
have to allow selection between hundreds of IdP then the NASCAR breaks down and there is more opportunity
for specialist IdP like UnitedID to be accepted.

John B.

On Mar 20, 2014, at 9:47 PM, Nat Sakimura <sakimura <at> gmail.com> wrote:

> Removing: board <at> openid.net and board-ec <at> openid.net from the Cc list and adding openid-general since
this is more of a community question and not the board discussion. 
> 
> 2014-03-21 7:31 GMT+09:00 Kaliya Identity Woman <identitywoman <at> gmail.com>:
> I asked Don last time we were in person if the GSMA in its use/adoption of OpenID was going to enable people to
easily have more then one profile on their device. He basically said they hadn't thought of it and in effect
said "nope". 
> 
> Actually, this is not true. Many telcos are perfectly willing to give ability to the consumers multiple
"identities". 
> The credential being SIM based and the support of multiple "identity/partial identity/paersona" is an
orthogonal thing. 
> Perhaps Torsten can chime in here as well. 
> 
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
>  <at> _nat_en
> _______________________________________________
> general mailing list
> general <at> lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20140321/f3ff1f02/attachment-0001.html>

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

Message: 5
Date: Fri, 21 Mar 2014 07:36:36 +0100
From: Torsten Lodderstedt <torsten <at> lodderstedt.net>
To: Nat Sakimura <sakimura <at> gmail.com>, Kaliya Identity Woman
	<identitywoman <at> gmail.com>
Cc: "openid-general <at> lists.openid.net"
	<openid-general <at> lists.openid.net>
Subject: Re: [OpenID] [OpenID board] [Board-ec] Fwd:
	JTC1_N13405-Proposal for a liaison C between Open ID Foundation and
	ISO/IEC JTC1 SC27 WG5
Message-ID: <9m200p3klmqd6pem2uj9vtog.1395383796676 <at> email.android.com>
Content-Type: text/plain; charset="utf-8"

Different operators have different capabilities and identify management philosophies. Due to our
philosophy, which is rather decoupled from mobile subscriptions, Deutsche Telekom could offer an
option to have multiple identities (where at most one of them is authenticated with the SIM card). It would
require users to select their id per RP, which might be considered a UX issue.

Regards,?
Torsten.

-------- Urspr?ngliche Nachricht --------
Von: Nat Sakimura <sakimura <at> gmail.com> 
Datum:21.03.2014  01:47  (GMT+01:00) 
An: Kaliya Identity Woman <identitywoman <at> gmail.com> 
Cc: openid-general <at> lists.openid.net 
Betreff: Re: [OpenID] [OpenID board] [Board-ec] Fwd: JTC1_N13405-Proposal for a liaison C between Open
ID Foundation and ISO/IEC JTC1 SC27 WG5 

Removing: board <at> openid.net and board-ec <at> openid.net from the Cc list and adding openid-general since
this is more of a community question and not the board discussion.?

2014-03-21 7:31 GMT+09:00 Kaliya Identity Woman <identitywoman <at> gmail.com>:
I asked Don last time we were in person if the GSMA in its use/adoption of OpenID was going to enable people to
easily have more then one profile on their device. He basically said they hadn't thought of it and in effect
said "nope".?

Actually, this is not true. Many telcos are perfectly willing to give ability to the consumers multiple "identities".?
The credential being SIM based and the support of multiple "identity/partial identity/paersona" is an
orthogonal thing.?
Perhaps Torsten can chime in here as well.?

--

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
 <at> _nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20140321/e29d5132/attachment-0001.html>

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

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

End of general Digest, Vol 85, Issue 4
**************************************
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

Gmane