[OpenID] CheckIDRequest with Big AX

Tue Dec 30 17:19:39 UTC 2008

The power of openid is that app developers don't need to do oauth on the backflow (more core library code, more management, more control issues) or a web service (more core library code, more management, more control issues).

I know I'm stepping on toes here, but that's the point! Merger with OAUTH has to make a functional difference, not just repeat what already exists in a different form. Don't want two management and control frameworks.

We have the concept that (a) a websso flow between OP and SP involving the user has setup a persistent association, and (b) the SP and OP/AX agent can now freely ping each other using AX (with no visible experience), (c) no identity verification service need be requested (identity=openid=null) allowing a developer to use the AX extension with the core assertion protocol without worrying about claimedids (d) the nature of AX schema is such that there are an infinite number of attribute-based protocols that an app developers can now create. Multi-valued AX response can be sending back 1000 photos if it wants, or 7 .crt files (certificates) in a user's chain. The attribute values may even be defined as ordered (since the schema is [properly] vendor-driven).

Of course the security context for that AX-only flow is one of the OP (as user AGENT) is talking to SP (local session derived from an openid assertion). That is, the user is talking to the user, as represented by two agents. A better name for the OP in an AX-only flow would be AX authority, or similar. The AX authority is likely to be a proxy - a data service front ending ldap, or sql, or some data object library.

Now we just have to be a little careful. In the culture of OpenID, the OP is operating under UCI rules (data ownership and release control are _culturally_ in the hands of the user, not the vendor/SAAS operating the OP site as in the more traditional FaceBook & VeriSign TTP cultures). However, the same is not true for the SP. As in the case of the Foundation itself, the SP can be operating under (published) rules that TAKE OWNERSHIP of information, once introduced into the SP site. A contract binding exists, under the trust model, agreeing to ownership issues, legal obligations of the parties, etc. And, as we now know, XDI envisions itself as playing the role of setup/management/control of such contract bindings (in the openid world).

Whether the app developers uses the openid backflow or foreground flow seems to me to be a minor matter of engineering and practicality. The data flow is simply AX-only messages - with null identity verification fields - over an openid association that brings to the flow the benefits of the data origin authentication service of the respondent assertion's signed mac. Just because AX-only flows over associations pass through the foreground channel does NOT mean the user's focus has to be take away from the current task, in GUI terms. There does not HAVE to be a page referenced at the OP/AX server that says: do you give consent to the release of these 1000 pictures and contacts. If the trust model of the OP/SP (i.e. an XDI document) is such that consent is implied under the contract binding, there may be a background delta-based sync going on every 1m, in a hidden iframe. If the association lifetime expires, then I can there being a need for the app to force an full run of openid auth, to re-establish the claimedid by invoking the identity verification service, and thus attempt to give new life to the local sessions at SP and/or  OP.

From: larry drebes [mailto:ltd at janrain.com]
Sent: Tuesday, December 30, 2008 6:03 AM
To: Pat Cappelaere
Cc: Peter Williams; general at openid.net List
Subject: Re: [OpenID] CheckIDRequest with Big AX

The use case is legit.   The OpenID flow is through the user agent, the user is redirected to the OP, the OP redirects back to the RP.  For backchannel access to data (where access has previously been granted), oauth or a callback url are much simpler flows than than going through the user agent redirect.    larry-
On Tue, Dec 30, 2008 at 5:25 AM, Pat Cappelaere <pat at cappelaere.com<mailto:pat at cappelaere.com>> wrote:
I think that AX is used in its designed role here.
The user grants access to his information.
The SP ought to be free to access that information at anytime and update/store stuff at anytime, right?
This seems reasonable to me and very appropriate to leverage that capability at the enterprise level.
Pat.

On Dec 30, 2008, at 6:59 AM, Peter Williams wrote:

This begs a wider question concerning AX. The underlying issue relates to my own confusion over the wider role of AX (expressed in a thread a week or two ago).

For Dick, evidently AX is the extensible form of sreg - and is about a visible user-centric experience (e.g. a signup wizard). It's little more. There is a bit of stuff about AX update.

For others, two websites may be exploiting an _existing_ openid pairwise security association to signal each other over that authenticated channel, using AX extensions for requests/response FOR PER-APPLICATION PURPOSES. This may be occurring OUTSIDE a visible user experience (such as signup form population). The user may have no interactive role. One might only set a config policy of "please sync me every 10m", and 10 AX transactions occur over 10 hidden iframes (every 10m).

Im with Pat on AX; doing the kind of thing he is doing is what it seemed to be saying it was for...

As with XRI, the power of openid is its architecture and the enabling that XRI/XDI/AX/URls provide to app developers. It's not the particular GUI practice today - which at the end of the day is just another websso protocol that also ran. Since any and all websso is however a fundamental enabler (because it brings with it solutions to security associations, consent, and impersonated session management), its what now follows from and develops on the openid architecture that is the _really_ interesting stuff.

From: general-bounces at openid.net<mailto:general-bounces at openid.net> [mailto:general-bounces at openid.net] On Behalf Of larry drebes
Sent: Tuesday, December 30, 2008 3:19 AM
To: Pat Cappelaere
Cc: general at openid.net<mailto:general at openid.net> List
Subject: Re: [OpenID] CheckIDRequest with Big AX

Hi Pat,
The normal behavior for an OP is to assume the user is in the loop.  With javascript enabled the form POST submit should happen automatically, for the vast majority of time this is not pestering the user.
larry-
On Mon, Dec 29, 2008 at 7:46 PM, Pat Cappelaere <pat at cappelaere.com<mailto:pat at cappelaere.com>> wrote:
I have an interesting problem.

I am trying to make a CheckIDRequest along with a few experimental AX.
Problem is that my attributes are fairly large and could overflow the
GET.
The Janrain Ruby library detects that and turns the response into a
secondary form.  A user has to hit continue for the form to do a
post.  This is fine if there is a user in the loop (although confusing
at best) but this is not my case.  I do not have a user in the loop.
I am really trying to authenticate an application consumer that
happens to have an openid and trying to get its pubic key in order to
do the OAuth dance using AX... cool stuff...

My questions are:

Is this the normal behavior of an OP?

Should I try to patch the server library to return a directPOST?

Or get my consumer to break down the request in two parts?  I am not
quite sure how the second part would look like though...

Any suggestions?

Thanks,

Pat.

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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081230/1bdf2288/attachment-0002.htm>