Raymond Drew Walker | 21 Jun 21:17 2016

[OpenID] Facebook & OpenID Connect

Does Facebook actually support/implement OpenID Connect at this time or if they are still just a supporter of the OpenID Connect project.

 

If the latter, what does the community trend seem to be for those who make use of OpenID Connect (via Google, etc) but also wish to make use of Facebook social logins as well. (ie. separate client implementation/support for OpenID Connect, Facebook Connect, Oauth2.0, etc. or something that ties everything together such as Google Firebase, etc?

 

Thanks much in advance,

— 

Raymond Walker
Software Systems Engineer StSp.
ITS Northern Arizona University

 

_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Phil Hunt | 21 Jun 20:53 2016
Picon

Re: [OpenID] [Openid-specs-ab] Profile for using SCIM with OpenID Connect

A question I received was about the apparent multiple ways to access a SCIM resource through the profile. In part this is because SCIM offers multiple ways in REST.  But also using the “/Me” path follows the pattern similar to Connect for the UserInfo endpoint. “/Me” is just the SCIM equivalent.

It is also important to remember that while Connect “sub” and SCIM “id” may be similar in format, it will often be true that the values are unique and distinct. One identifier refers to the authentication context, while the other identifier refers to the SCIM profile context.

So for backwards compatibility reasons, the thinking is not to force the two identifiers to be the same and to define “scim_id” to allow the client to use “sub” with OIDC protocol and “scim_id” with SCIM protocol.

Phil

On Jun 21, 2016, at 9:32 AM, Phil Hunt <phil.hunt <at> oracle.com> wrote:

Thanks Erik, found it (for some reason Facebook never notified me).

Using the “/Me” follows the pattern used by Connect for the UserInfo endpoint. “/Me” is just the SCIM equivalent.

However, in the broader use, we had some discussion that clients may want to know the actual id and location for the authenticated user for other reasons.  That said, we might argue that the client must actually do a scim get to the “/Me” endpoint to actually obtain the authenticated user’s id and resource location. 


On Jun 21, 2016, at 9:19 AM, Erik Wahlström <erik <at> wahlstromstekniska.se> wrote:

Hi Phil,
Did you get my 2 minute review? I sent it over facebook (that´s right :)) to make sure that the review was my me acting as an individual, not from my company.
/ Erik

On Tue, Jun 21, 2016 at 6:13 PM, Phil Hunt <phil.hunt <at> oracle.com> wrote:
Any comments or feedback? I know a number indicated they plan to read the draft.


On Jun 15, 2016, at 1:10 PM, Phil Hunt <phil.hunt <at> oracle.com> wrote:

Please find attached, a draft proposal from Chuck Mortimore and myself on using SCIM as an alternate endpoint for profile services in the context of Connect.

This specification defines:
a. Discovery metadata (scim_endpoint) indicating availability of a SCIM Protocol base endpoint
b. Dynamic registration metadata (scim_profile) used to indicate a client intends to use SCIM in addition to or instead of UserInfo
c. An additional ID Token claim (scim_id and scim_location) which specifies the SCIM resource endpoint and identifier associated with the authenticated subject.

By doing this, clients can avoid having to do an external authorization and another round of exchanges to access User profile information with full CRUD features.

Clients can also access SCIM’s more sophisticated query system to ask questions if the authenticated user has particular conditions (e.g. querying a sub-attribute such as “country” in the “addresses” attribute).  

As an example use case: A cloud provider wants to build a user-profile self-service portal. OIDC does the authentication of the user and allows the web service to access the CRUD features of SCIM for the updates.

<Draft: OpenID Connect Profile for SCIM Services.html>
<openid-connect-scim-profile-1_0.txt>




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


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




_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Cook Mick UK | 27 May 12:25 2016
Picon

[OpenID] usefull info

Hi,

 

I guess you are interested in that stuff, here is a useful link http://cyfrychapra.tristatepickers.com/aexzh

 

Cook Mick UK

_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Paul Hethmon | 3 May 23:20 2016

[OpenID] claims vs scopes vs extra

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

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

	aud
	iat
	exp
	iss

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

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

So, some specific questions:

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

thanks,

Paul

-----
Paul Hethmon
Chief Software Architect
paul.hethmon <at> clareitysecurity.com


_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Phil Hunt | 1 Apr 20:10 2016
Picon

[OpenID] Identity Events - GitHub site

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

The following drafts are available:

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

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

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

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

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

Thanks for your comments and feedback. 

Phil
_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
boris8479 | 1 Apr 01:31 2016
Picon

[OpenID] Some thoughts on Open ID Connect Session

Hi Community,

 

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

 

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

 

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

 

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

 

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

 

If you need my opinion how it can be improved:

 

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

 

Regards,

Boris Georgiev

_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Malithi Edirisinghe | 21 Mar 05:56 2016

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

Hi All,

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

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

Thanks,
Malithi

--

Malithi Edirisinghe
Senior Software Engineer
WSO2 Inc.

Mobile : +94 (0) 718176807
_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Paul Hethmon | 2 Mar 21:48 2016

[OpenID] Auth Request display param question

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

Discussion here or a pointer to something is greatly appreciated.

thanks,

Paul

-----
Paul Hethmon
Chief Software Architect
paul.hethmon <at> clareitysecurity.com


_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Paul Hethmon | 27 Jan 23:38 2016

[OpenID] discovery url vs issuer

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

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

	https://idp.clareitystore.net/idp/shibboleth


I’ve got my metadata at this URL:

	https://idp.clareitystore.net/idp/openid/configuration


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

Testing gives me:

0.000465 ------------ DiscoveryRequest ------------
0.000496 Provider info discover from 'https://idp.clareitystore.net/idp/openid/configuration'

0.000503 --> URL: https://idp.clareitystore.net/idp/openid/configuration/.well-known/openid-configuration

0.161675 [ERROR] IssuerMismatch:'https://idp.clareitystore.net/idp/openid/configuration' != 'https://idp.clareitystore.net/idp/shibboleth'


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

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

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

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

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

thanks,

Paul

-----
Paul Hethmon
Chief Software Architect
paul.hethmon <at> clareitysecurity.com


_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
John Bradley | 18 Jan 14:47 2016

[OpenID] Opened Summit in Santiago

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

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

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

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

[OpenID] Return Authorities to Client

Hi,

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

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

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

Gmane