[OpenID] OP initiated and RP to RP flows

[Peter Williams]

Let's go slower, for those of us whose minds must plod through formal
state machines.



1. let's assume: Consumer -> Consumer transfer of attributes is a
standard use case

2. Let's assume that RP1 and RP2 are OpenID Auth intelligent mode
capable, when performing OpenID Auth 2.0 protocol (latest draft,
non-FinalizedSpec-IPRwise)

3. Let's assume RP1 and RP2 each have complete feature set support, for
the OpenID AX protocol (latest draft, non-FinalizedSpec-IPRwise)

4. Let's assume RP1 and RP2 each trust OP1.

5. Let's assume we can always ignore the case of RP1 only relies on OP1,
whereas RP2 only relies on OP2.


Now, for two specific protocol entities on two real hosts:-


a. Presume RP1 has an existing OpenID-association with OP1

b. Presume RP2 has an existing OpenID-association with OP1


Let's review the stack entity interplay on Consumer=RP1:


I: User has a session on a Consumer RP1 website, which just relied on
OP1 via an OpenId Auth protocol run

II: Consumer RP1 invokes OpenID AX as initiator, for some attribute
contract payload, targeting an OP1 endpoint

III: OP1 attempts to fulfill the attribute contract payload

IV: OP1 initiates a second protocol run of OpenID AX, acting as
initiator - making fulfillment of the outstanding request pending on the
outcome

V: OP1 and RP2 engage in an OpenID AX protocol run, in which OP1 is
initiator, requesting role reversal

VI. (ASSUMPTION) OpenID AX has a use case intending that an OP
AX-endpoint can rely on an RP2 AX-endpoint to provide attributes

VII: Attributes are supplied by RP2, and relied upon by OP1 using the
OP1-RP2 OpenID association

VIII: OP1 caches the attributes for OpenID=RP2

IX: OP1 fulfills the pending AX request, which RP1 relies upon.


(There is prior art on that flow, note)


This flow should be called out in the OpenID AX spec, if the protocol
SHALL support such standardized interworking between AX endpoints
systems.

It should be in its own section, entitled something like: chained OpenID
AX protocol, with caching.

The case of each RP relying on a distinct OP should be specified.
Perhaps assumption 5 is not realistic.

When "chained OpenID AX protocol, with caching" handles
knowledge-attributes rather than object attributes, the case of
knowledge caching should be distinguished. For example: treating the
FOAF URL as discovery-knowledge, which helps drive the OP discovery,
limits inter-Consumer interaction, etc; and otherwise constrains the
chaining of AX requests by or between OPs.

-----Original Message-----
From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
Behalf Of Dick Hardt
Sent: Monday, July 30, 2007 11:16 AM
To: Recordon, David
Cc: general at openid.net
Subject: Re: [OpenID] OP initiated and RP to RP flows

For updating attributes in the AX spec, the OP initiates the flow.

Additionally,  AX expects flows of RP1->OP->RP2->OP->RP1 for fetching  
a claim from RP2 from RP1.

RP1 requests claim
OP discovers that RP2 has claim and sends user to RP2
RP2 stores claims at OP
OP then completes request to RP1

-- Dick

On 30-Jul-07, at 11:02 AM, Recordon, David wrote:

> I've seen it done with OpenID 1.1, though unsure from a technical
> perspective exactly how it was implemented.  Also unfortunately can't
> say who showed it to me, so we'll have to wait I guess to learn more
> about it. :-\
>
> --David
>
> -----Original Message-----
> From: general-bounces at openid.net [mailto:general- 
> bounces at openid.net] On
> Behalf Of Andrew Tomlinson
> Sent: Monday, July 23, 2007 5:58 AM
> To: general at openid.net
> Subject: [OpenID] OP initiated and RP to RP flows
>
> There seems to be some talk about OP initiated and RP to RP flows,  
> but I
> am not sure if/how OpenID can do it. Can someone more enlightened than
> me comment on this please?
>
> For "OP initiated" my searches only found
> http://connectid.blogspot.com/2007/05/openid-op-first.html and reading
> the OpenID 2.0 spec there is 10.1. "... Relying Parties SHOULD accept
> and verify assertions about Identifiers for which they have not
> requested authentication" and 13. "Discovering OpenID Relying Parties"
> which look promising...
>
> I couldn't find any mention of RP to RP flow (or RP1->OP->RP2). Is  
> this
> possible with OpenID 2.0? There are plenty of interesting uses for  
> this
> especially with "user not present" scenarios.
>
> I guess both of these are well out of scope. Can anyone confirm?
>
> Thanks,
>
> Andrew
>
> _______________________________________________
> 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