[OpenID] openid connect. what is it?

Tue Sep 24 14:14:58 UTC 2013

nameid and identityprovider are custom field for JWT.
In JWT proper, user_id instead of nameid but they would server the same
purpose.
If you are not doing anything custom, you may eventually end up with the
standard claims as well.

In Connect, at the beginning, we considered having structure in access
token iteself, but the WG decided that we should keep the access token to
be opaque and have ID Token in addition.

ID Token is a signed JWT. It acts as a detached signature for the access
token as well.

OpenID Connect defines Userinfo endpoint and Discovery, Registration,
Session Management as well.
>From Userinfo endpoint, you can obtain user profile data. It can translate
the access token to other tokens to be used on other endpoints as well. (It
may return multiple endpoint_url=token pair.)

2013/9/21 Peter Williams <home_pw at msn.com>

>  Ok. Really that's its really a standardized oauth, with websso between
> as and idp. Furthermore, one can signal choice of attribute contracts, as
> an sp. Furthermore, the idps shown in the home realm screen is configured
> per sp.
>
> In my case, we don't mint (or format) the jwt. We borrow a Microsoft azure
> service for that (mostly so they can ensure conformance and
> interoperability). They choose to put the user grant in a namid field (of
> an access token).
>
> Standardizing claim names in an id token feels like a rats nest, since
> this had failed a dozen times already. We did ensure a transforming wsfedp
> agent can remint tokens (mapping claim names and value syntaxes), knowing
> from our own industry that every sp affiliation wants things done
> differently (mostly to compete with other sp affiliations, add value, or
> instrument protectionism).
>
> All that remains is to understand how the id cert relates to the access
> token. For thus the relationship feels almost identical to the x509 authz
> cert (pac), and the x509 id cert (with 3 extensions bearing user
> naming/descriptive attribute).
>
> Is there anything more to openid connect, at heart?
>
> As I say, I have to decide whether to bother advocating for it, or not,
> now.
>
> Sent from my Windows Phone
>  ------------------------------
> From: Nat Sakimura <sakimura at gmail.com>
> Sent: 9/20/2013 6:58 AM
>
> To: Peter Williams <home_pw at msn.com>
> Cc: openid-general at lists.openid.net
> Subject: Re: [OpenID] openid connect. what is it?
>
>  OpenID Connect at its core is the standardized JWT (JWS)
> and the way to ask for specific characteristics.
> You seem to be doing more or less the same
> thing as OIDC. Main difference seems to be the
> fact the OIDC leaves the access token  alone
> as implementations may want it intact.
> Obviously, the claim names also are different.
>
> =nat via iPhone
>
> Sep 20, 2013 15:50、Peter Williams <home_pw at msn.com> のメッセージ:
>
>   Oauth client website server induces users browser to visit authz
> endpoint. This is a websso dp which concludes websso with an idp (which
> does RSA baysian network tracking/identification of user devices, from
> passive tracking signals  left by web standards (insecurity properties).)
> upon release of jwt over websso (wsfedp in our case), delegation record is
> registered for websso session and associated one time code goes off to
> website registered to vendor running oauth client.
>
> Client (server thread, here) exchanges one time code for access token -
> which is another jwt blob, signed with rsa, with namid field. Its value is
> the nameid from websso assertion. ( In another profile, the nameid is the
> entire websso assertion.)
>
> Now that I understand, being a minor variation of 30 year old x500
> security services, using alternative signed blob formats and alternative
> chaining protocols between server agents.
>
> If the above is oauth2, its fine. It looks pretty interoperable, based on
> a signed blob agreement, a naming record, and a couple of conversation
> protocols.
>
> I hope I answered the first paragraph question.
>
> If openid connect now just has the authz endpoint show an idp picker
> screen, this I can do (obviously). The idp must support openid, saml2, or
> wsfedp for websso. ( If its wsfedp, there can be a chain of issuers, any
> one or several of which can show the home realm selector experience).
>
> Sent from my Windows Phone
>  ------------------------------
> From: Nat Sakimura <sakimura at gmail.com>
> Sent: 9/19/2013 11:06 PM
> To: Peter Williams <home_pw at msn.com>
> Cc: openid-general at lists.openid.net
> Subject: Re: [OpenID] openid connect. what is it?
>
>  Let me then ask this: With OAuth, how did you communicate the
> information about the authentication event and of the identity between the
> server and client in an inter-operable manner?
>
>  In short, OpenID Connect is something that provides it.
>
>  For JW*, http://self-issued.info/ would be a good resource.
>
>  OpenID Connect has no UI at all. Selector like thing is Account Chooser,
> which is another specification being worked on at OpenID Foundation.
> For a basic description of what it is, perhaps you can look at
> https://www.accountchooser.com/learnmore.html .
>
>  Best,
>
>  Nat
>
>
> 2013/9/20 Peter Williams <home_pw at msn.com>
>
>  Good try. But it didn't deliver the story.
>
> It said that id cert standardizes some Facebook thing (that I know nothing
> about, since Facebook is irrelevant to us).
>
> It seemed to hint at the old (pre NSA surveillance state) position, of
> making idps (or as partners) govern RP privacy policies, limiting who gets
> which sensitive claims.  In a total surveillance climate, this American
> privacy- initiatives looks silly (and deceptive even).
>
> We were left with some academic schema statements based on inverted models
> of identity (you are the attributes attached to different relations). The
> point was lost. I felt like I was learning about an isam file structure
> (without knowing why).
>
> I .was confused about the point of showcasing yet more jw* standards. All
> I guessed was that things will be day reimplement ws)secureconversation,
> perhaps, swapping byte format. This seemed to be a wap moment (having
> designed for a phone world * pre* broadband rate data plans, and handheld
> cpu/ram bigger than my university had for the entire engineering faculty.
>
> I was left with only one hint, from phone UI pictures. It was that oauth
> facilitates their being a native logon app, that supports other apps on the
> phone in that idps ecosystem. (and maybe other idp app sellers, if 2 idp
> chhose to coordinate - like all, yahoo and live in the era of I'm
>
> Just as I waited 3y for oauth to mature (and finally makes its case),
> wondering whether I should just ignore openid connect - and look again in
> 2-3 years?
>
> Sent from my Windows Phone
>  ------------------------------
> From: Nat Sakimura <sakimura at gmail.com>
> Sent: 9/19/2013 4:16 PM
> To: Peter Williams <home_pw at msn.com>
> Cc: openid-general at lists.openid.net
> Subject: Re: [OpenID] openid connect. what is it?
>
>   This page may help you understand what OpenID Connect is based on your
> understanding of OAuth.
>
>
> http://nat.sakimura.org/2013/07/05/identity-authentication-oauth-openid-connect/
>
>  ID Token has been used by google for sometime.
> It's predecessor, signed request of Facebook has been used very widely as
> well.
>
>  =nat via iPhone
>
> Sep 20, 2013 7:33、Peter Williams <home_pw at msn.com> のメッセージ:
>
>   Having deployed an isp-class oauth service, I feel I know what OAUTH is
> (finally). Rather than have an embedded authentication website, it does
> websso to an IDP. In other words, the AS is itself an websso SP.
>
> Now, I understand that a few tweaks of messages in OAUTH allows that
> AS-webssoSP bridge to invoke a selector screen - by which users choose IDPs
> from a list. And, I understand that the OAUTH tweaks might indicate which
> of several IDP lists to use, where a OAUTH IDP-class service can tune-its
> self up to offer multiple private label experiences, selected by some or
> other label sent in an OAUTH message.
>
> Is that ALL opened "connect" is? (a way of hosting lots of identity
> selector pages, together with the config of the IDP metadata, etc; and a
> way of choosing which page of selections to present)?
>
> Ive also seen hints that "companion" JWTs  might accompany the access
> token. Known as id-tokens, they don't actually seem to exist in the wild
> (not having escaped the paper lab, yet). As far as I can tell, they are
> just JWTs with more than the nameid claim, thereby avoiding a per-IDP API
> call (just to collect a yahoo API's vs facebook APIs member record
> claimset).
>
> Is this opened connect?
>
> I've also seen hints that the companion JWT is supposed to be a mobile
> account-linking record; similar to the old account linking service elements
> of OASIS. is this opened connect? If there is "evidence" that several
> access tokens all relate to a common persistent name (ahem XRD id, for
> structured names) represented by the id-token, is this openid connect?
>
>
>
>
>
>  _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>
>
>
>
>  --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
>  _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>
>

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