.Nat Zone - Latest Comments

Re: OpenID Connect IdP on iPhone

Nat Sakimura — Wed, 18 Apr 2012 08:36:07 -0000

it depends on the use case you are talking about.
In many cases, only the fact that the same user (who has paid) is returning is needed. That is pseudonymity. In fact, for most commercial transaction, that is what is needed. It is not me saying. I had a committee of financial institutions, internet commerce companies etc. a couple of years ago discussing this issue for half a year, and this was their conclusion. For this, self-issued IdP is perfectly adequate. In fact, it is much more secure than password in the case of IdP on the phone, so it is potentially more desirable. Think of this: when you walk into a store, do you need impartial third party to accompany you? No. Requiring impartial third party is a "distrust by default system" and is non-starter.

For the claims other than authentication context, the authoritative source for the claim differs from a claim to another. For example, while your age may be verified by the birth registry or something like that, you are perfectly good authority for the address that the goods you bought needs to be delivered. So, there is no single authority for your attributes.

When you need a third party attested claims, you can get the signed claims and store it in the Phone IdP (claims aggregation) as well as providing the reference to the source (distributed claims). That is the beauty of the OpenID Connect protocol.

Re: OpenID Connect IdP on iPhone

Nat — Wed, 18 Apr 2012 08:21:47 -0000

A.1 That's easy. If something like Account chooser supports phone IdP in parallel to the normal IdPs, that is done.

A.2 This is more challenging. It is the session transfer between the PC browser and the phone. Some of the ways that we have been experimenting is to use QR code, Bluetooth, WiFi, and 6 digits code. Need more time to figure it out.

Re: OpenID Connect IdP on iPhone

George Fletcher — Tue, 17 Apr 2012 12:37:10 -0000

Nice! A couple thoughts come to mind...

1. When using my phone I want the choice of whether to use the local IdP or a remote one. For instance, I might want to log into some site with my Google credentials because activity can then be easily posted to G+

2. It would be very cool, if I could use the IdP on my smart phone when surfing the web on my laptop:) Not sure how to register that IdP as an OpenID Connect endpoint the website can reference.

Re: OpenID Connect IdP on iPhone

Dj — Mon, 16 Apr 2012 13:42:04 -0000

Perhaps I am missing something basic here, but... the idea of the IdP and the client being one and the same seems to sidestep the foundational principle that the RP can trust the IdP as an impartial third party. If you are authenticating yourself and making claims about yourself and the authenticating party is also under your control then there is a serious segregation of duties issue. How is the RP to trust the IdP on every phone?

like i said - perhaps I missed something here...

thanks
derek

Re: Scopes and Claims in OpenID Connect

NimbusDS.com — Thu, 12 Apr 2012 15:45:55 -0000

Nat, thanks for this article, it helped us a lot in our implementation.

One question though: aren't all scope-derived claim requests supposed to be optional, including the email and address ones?

I found the following in the latest spec version: http://openid.net/specs/openid...

"The Authorization Server MAY fully or partially ignore the scope values
requested by the Client based on the Authorization Server policy or
the End-User's instructions."

This implies that "email", "verified", and "address" should also be marked {optional:true}.

Re: OpenID Connect in a nutshell

Nat Sakimura — Wed, 01 Feb 2012 22:26:39 -0000

Good!

We should promote John's post.
It is a public safety issue :-)

Re: OpenID Connect in a nutshell

Eric Sachs — Wed, 01 Feb 2012 20:11:10 -0000

I noticed the addition of the sentence "
The client MUST verify that the aud matches its client_id and iss matches the domain (including sub-domain) of the issuer of the client_id." That addresses my concern which John Bradley discussed in more detail at
http://www.thread-safe.com/201...

Re: OpenID Connect in a nutshell

Nat Sakimura — Mon, 30 Jan 2012 09:47:12 -0000

OpenID Connect is a new generation of the internet identity protocol. Technically, it is fundamentally different than OpenID 2.0. From the point of view of the non-technical end user, however, it would be hard to see the difference.

This article is written for the technical audience. There is a separate article for non-tech people at http://nat.sakimura.org/2011/0... .

Re: OpenID Connect in a nutshell

Robert (Jamie) Munro — Mon, 30 Jan 2012 09:38:24 -0000

Could you add a paragraph at the beginning to say what OpenID connect actually is? Is it OpenID 3.0 with a cooler name, or is it fundamentally different? Assuming both the website and OpenID provider support it, what difference will a random non-technical user see?

Something like "OpenID connect is the new version of open ID that in addition to letting you log in also ..."

Re: OpenID Connect in a nutshell

Nat Sakimura — Thu, 26 Jan 2012 01:25:40 -0000

The terminology that I am using here is that of IETF OAuth 2.0., as that is the primary readership.

Re: OpenID Connect in a nutshell

Font — Wed, 25 Jan 2012 21:15:40 -0000

At least part of the confusion comes from the terminology such as "Client" which is overloaded. For example, the service provider term of SAML roughly (but not exactly if you want to be pedantic) corresponds to Client; and IdP corresponds to server.

Re: OpenID Connect in a nutshell

Justin Richer — Wed, 25 Jan 2012 10:23:21 -0000

This is when I should learn to keep my mouth shut. :)

Re: OpenID Connect in a nutshell

Nat Sakimura — Wed, 25 Jan 2012 10:01:27 -0000

Yes. Preventing replay of id_token that was issued to someone else is important and that is why there is aud claim. Thanks for pointing out.

Re: OpenID Connect in a nutshell

Nat Sakimura — Tue, 24 Jan 2012 21:59:57 -0000

So, do you have any concrete text proposal?

Re: OpenID Connect in a nutshell

Breno de Medeiros — Tue, 24 Jan 2012 21:11:09 -0000

It would be nice to emphasize this point more.

Re: OpenID Connect in a nutshell

Nat Sakimura — Tue, 24 Jan 2012 19:33:25 -0000

Or, would you like to write it?

Re: OpenID Connect in a nutshell

Eric Sachs — Tue, 24 Jan 2012 19:22:00 -0000

What about the client checking that the aud (audience) field is actually for this client, and not another one being replayed?

Re: OpenID Connect in a nutshell

Justin Richer — Mon, 23 Jan 2012 16:37:21 -0000

This is a great summary, and I think it helps to clarify many of the moving pieces from the clients' perspective. I think it'd be helpful to get something similar from a server side. "So you want to be an IdP?"

Re: OpenID Connect in a nutshell

Nat Sakimura — Sat, 21 Jan 2012 10:49:30 -0000

Welcome.

Re: OpenID Connect in a nutshell

Nat Sakimura — Sat, 21 Jan 2012 10:49:13 -0000

I will. The client should verify the id_token by itself (if capable of doing crypto itself), or call check id endpoint to verify it. It does not have to call userinfo endpoint unless it wants more "claims."

Re: OpenID Connect in a nutshell

atom — Fri, 20 Jan 2012 17:08:35 -0000

Good post Nat! It would be helpful if you clarified whether or not clients should verify the id_token and also call the user_info endpoint after receiving an assertion.

Re: OpenID Connect in a nutshell

Thomas — Fri, 20 Jan 2012 11:04:06 -0000

Thanks Nat, this is very helpful.

Re: Dummy’s guide for the Difference between OAuth Authentication and OpenID

Matt Tebo — Thu, 12 Jan 2012 12:13:30 -0000

Nice summary Nat.

Re: Entity, Identity, Privacy

Nat Sakimura — Sun, 27 Nov 2011 16:23:04 -0000

Then you are mistaken. Entity's existence in this context has nothing to do with administrative construct.

Re: Entity, Identity, Privacy

Enzion Xavier — Tue, 25 Oct 2011 15:33:38 -0000

A data process that documents/defines/specifies that which the data correlates to for managed purposes. Such as; registering a live birth is an administrative process.