[OpenID] OP initiated and RP to RP flows

Tue Jul 31 15:02:21 UTC 2007

I am not clear on the mechanism for V/VI in Peter's email or "OP discovers
that RP2 has claim and sends user to RP2" in Dick's email.

Is the assumption that RP2 has already let the OP know that it can provide a
specific attribute? Would this be a side effect to a store_request generated
beforehand from RP2? - or have I missed something? Why doesn't store_request
need a openid.ax.updateprovider_url to give a place for the OP to request
updates to the attributes? - otherwise how does the OP know where to go?

Here is a potential use of AX which is an example of RP to RP interchange
(numerals in brackets refer to a rough match-up to Peter's commentary):

1. (VI) RP2 registers ability to provide a private_photo_gallery_feed
attribute the value is a url with an embedded secret (store_request)
2. (VII/VIII) User accepts at OP site that RP2 should be their
private_photo_gallery_feed provider and caches this value
3. (I) User goes to RP1 which provides a private homepage and user wants to
include an image they have stored at RP2
4. (II) RP1 makes fetch_request for private_photo_gallery_feed attribute
5. (III) User is bounced to OP to see whether RP1 is allowed to make such a
request
6. (IV/V) OP optionally goes to RP2 to refresh the attribute (the bit I am
vague on)
7. (IX) OP gives the url with the secret in it to RP1 as it sends the user
back to RP1 
8. OpenID's job is done
9. RP1 performs an out of band request to that URL and gets access to the
user's private photo gallery and allows the user to select the photo
10. RP1 can keep talking to RP2 behind the scenes without further
authentication until the secret is expired/removed

Is this the right way to go about this with OpenID?

Andrew

-----Original Message-----
From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
Behalf Of Peter Williams
Sent: 30 July 2007 20:40
To: Dick Hardt
Cc: general at openid.net
Subject: Re: [OpenID] OP initiated and RP to RP flows

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
_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general