Sam DT | 21 Mar 09:18 2015
Picon

[OpenID] openID provider / server setting

Hi,

I want to make my own local host an openID provider for the purpose of a class assignment.
The relying party that i have configured should redirect the user to my localhost page where i have hosted the server for authentication.
Can you tell me if this is possible using any openID library?

I should be very thankful
_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Manger, James | 17 Feb 05:41 2015

[OpenID] Switching from OpenID 2.0 to OpenID Connect for Google logins to openid.net

Hi,

 

Signing in to the OpenID Foundation as a member (at https://openid.net/foundation/members/) using my Google account does work, but with the following warning:

 

  OpenID 2.0 for Google accounts is going away.

  Developers should migrate to OpenID Connect by April 20, 2015.

  Learn more.

 

It seems the foundation (via a Janrain widget) has not migrated to OpenID Connect. Is such a migration planned or in progress?

 

[If you want to see the warning yourself you may need to first revoke access for signin.openid.net at Google’s “Account permissions” page.]

 

--

James Manger

 

_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Vladimir Dzhuvinov | 18 Nov 11:20 2014

[OpenID] Dev libraries page: Link and details update

Hi guys,

In the libraries section:

http://openid.net/developers/libraries/#jwt

The link to the Nimbus JOSE+JWT library is no longer valid, here are the
updated details and info on the target environment as well:

***
Nimbus JOSE+JWT

http://connect2id.com/products/nimbus-jose-jwt

Nimbus JOSE+JWT is an open source (Apache 2.0) Java library that
implements the Javascript Object Signing and Encryption (JOSE) spec
suite and the closely related JSON Web Token (JWT) spec. Developed by
Connect2id.

License: Apache 2.0
Supports: JWS, JWE, JWT
Target Environment: Java 6, 7 or 8
***

Thanks,

Vladimir

--

-- 
Vladimir Dzhuvinov :: vladimir <at> connect2id.com
Takahiko Kawasaki | 24 Oct 13:16 2014
Picon

[OpenID] New item to be added to "Libraries, Products, and Tools"

Hello,

I'd like to ask someone to add a new item to the list in
the "Libraries, Products, and Tools" page.

    http://openid.net/developers/libraries/

What steps should I take and whom should I ask to?

Best Regards,
Takahiko Kawasaki
_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Chris Messina | 17 Sep 20:40 2014
Picon

[OpenID] Auth0

Has anyone checked out/been in touch with the Auth0 folks?

https://auth0.com/

--
  
Chris Messina 
chrismessina.me
    

This email is:   [ ] shareable    [] ask first   [ ] private
_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Mike Jones | 17 Sep 03:14 2014
Picon

[OpenID] FW: Review of Proposed Implementer’s Draft of OpenID 2.0 to OpenID Connect Migration Specification

 

 

From: Mike Jones
Sent: Tuesday, September 16, 2014 6:11 PM
To: specs <at> lists.openid.net
Subject: Review of Proposed Implementer’s Draft of OpenID 2.0 to OpenID Connect Migration Specification

 

The OpenID Connect Working Group recommends approval of the following specification as an OpenID Implementer’s Draft:

·         OpenID 2.0 to OpenID Connect Migration 1.0 – Defines how to migrate from OpenID 2.0 to OpenID Connect

 

An Implementer’s Draft is a stable version of a specification providing intellectual property protections to implementers of the specification.  This note starts the 45 day public review period for the specification drafts in accordance with the OpenID Foundation IPR policies and procedures.  This review period will end on Friday, October 31, 2014.  Unless issues are identified during the review that the working group believes must be addressed by revising the drafts, this review period will be followed by a seven day voting period during which OpenID Foundation members will vote on whether to approve these drafts as OpenID Implementer’s Drafts. For the convenience of members, voting may begin up to two weeks before October 31st, with the voting period still ending on Friday, November 7, 2014.

 

This specification is available at:

·         http://openid.net/specs/openid-connect-migration-1_0-06.html

 

A description of OpenID Connect can be found at http://openid.net/connect/. The working group page is http://openid.net/wg/connect/.  Information on joining the OpenID Foundation can be found at https://openid.net/foundation/members/registration.  If you’re not a current OpenID Foundation member, please consider joining to participate in the approval vote.

 

You can send feedback on the specifications in a way that enables the working group to act upon your feedback by (1) signing the contribution agreement at http://openid.net/intellectual-property/ to join the working group (please specify that you are joining the “AB+Connect” working group on your contribution agreement), (2) joining the working group mailing list at http://lists.openid.net/mailman/listinfo/openid-specs-ab, and (3) sending your feedback to the list.

 

-- Michael B. Jones – OpenID Foundation Board Secretary

 

(This notice has also been posted at http://openid.net/2014/09/16/review-of-proposed-implementers-draft-of-openid-2-0-to-openid-connect-migration-specification/.)

 

_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Adam Dawes | 25 Aug 15:43 2014
Picon

[OpenID] October 27 OpenID Workshop before IIW

The OpenID Foundation is hosting a workshop reviewing the status of each of the Foundation's current projects on Monday, October 27, 2014 in Mountain View California the day before the Internet Identity Workshop.

 

This event is a great way to learn more about and participate in the Foundation's efforts to create Internet standards that will simplify authentication across the web, apps, and mobile devices. 

 

The preliminary agenda is: 

  • Lunch and networking 11:45am to 1pm.
  • Account Chooser working group  1:00 - 2:00
  • OpenID Connect working group  2:00 - 3:00
  • Mobile Profile working group       3:00 - 4:00
  • Native Apps working group         4:00 - 5:00

The foundation is also in the process of chartering a working group on healthcare data exchange. So stay tuned, as this may get added to the agenda.

 

Please register to attend at:

https://openid-wg-oct-2014.eventbrite.com


Non Members are welcome to attend, but must be aware of the OIDF IPR policy.

NOTICE: An OpenID IPR contribution agreement is not mandatory in order to participate in this workshop.  If participants provide feedback, they (on behalf of themselves and any organization they represent) are deemed to agree that: Attendee gives the OIDF the right to use their feedback and comments.  Attendee grants to the OpenID Foundation a perpetual, irrevocable, non-exclusive, royalty-free, worldwide license, with the right to directly and indirectly sublicense, to use, copy, license, publish, and distribute and exploit the Feedback in any way, and to prepare derivative works that are based on or incorporate all or part of the Feedback for the purpose of developing and promoting OpenID Foundation specifications and enabling the implementation of the same.  Also, by giving Feedback, attendee warrants that they have rights to provide this feedback.  Please note that feedback is not treated as confidential and that OpenID Foundation is not required to incorporate feedback into any version of an OIDF specification.


_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
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,

   Victor Ake
   VP Customer Innovation & Co-founder
   http://www.forgerock.com
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

Gmane