[OpenID] CheckIDRequest with Big AX

Tue Dec 30 19:34:43 UTC 2008

fyi Peter: this is too long of a rant for me read

If you are won't take the time to make your point quickly, I won't  
take the time to try and figure out what it might be.

Nothing personal -- just sharing. :-)

-- Dick

On 30-Dec-08, at 9:19 AM, Peter Williams wrote:

> 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>  
> 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]  
> On Behalf Of larry drebes
> Sent: Tuesday, December 30, 2008 3:19 AM
> To: Pat Cappelaere
> Cc: 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>  
> 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
> http://openid.net/mailman/listinfo/general
>
>
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
> _______________________________________________
> general mailing list
> 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/02e177a3/attachment-0002.htm>