Wednesday, April 23, 2008

OAuth & ID-WSF Authz Models

(rev'd to clarify Andy's comment/question about the ID-WSF sequence)

(ignoring message authentication mechanisms)

OAuth Sequence

1) Alice is at - the site wants her X identity attribute
2) Alice indicates that X is maintained at
3) redirects Alice to
4) asks Alice 'OK for to get X?'
5) Alice says yes
6) asks for X
7) returns X to

ID-WSF Sequence

1) Alice is at - the site wants her X identity attribute
2) discovers that X is maintained at
3) asks for X
4) Not yet having Alice's permission, asks for Alice to be redirected to it
5) asks Alice 'OK for to get X?'
6) Alice says yes
7) re-asks for X
8) returns X to


=andy.dale said...

2 questions...

In the ID-WSF flow, step 7, does IHave actually return Alice to IWant with the value for X? or does IWant repeat the request, step 3, once Alice has returned?

My understanding is that there is more capability to 'blind' Alice's identity in ID-WSF... can you show how that plays in this simple comparison?


Andy Dale

Paul Madsen said...

Hi Andy, wrt the two parts of your question

1) the latter. ID-WSF doesn't use browser redirects to move attributes so, once Alice has been returned to IWant after giving consent, IWant will resend (its SOAP request)

I'll rev the sequence to clarify

Full details in ID-WSF Interaction Service spec -

2) ID-WSF allows for IWant & IHave to neither have a business relationship (and so no key set-up ala OAuth), nor have agreed upon an identifier to use for Alice.

In this case, the Discovery Service DS (hinted at in Step 2) will ensure that the security token it returns to IWant (this to be sent to IHave in Step 3) will be both

a) be meaningful to IHave (so that it can look Alice up)
b) opaque and meaningless to IWant

IWant can get Alice's X, but would not necessarily have any persistent identifier for her.

In this sense, we have overloaded the 'discovery' aspect - the DS also acts as an STS in order to broker trust.