[WG-UMA] OAuth Dynamic Binding - Web App

Eve Maler eve at xmlgrrl.com
Tue Jul 27 20:45:59 EDT 2010


So the "WWW" component (from Maciej's diagram) would be making the initial approach to the AS? That seems to make sense. Would love to hear Nat's comments based on his mobile experience, and comments from others, as well.

	Eve

On 23 Jul 2010, at 3:37 AM, Domenico Catalano wrote:

> Hi,
> 
> here is an alternative pattern for mobile client registration, maybe, close to iPhone App lifecycle ;)
> Attached a high-level diagram which shows the possible entire process:
> 
> 1. Developer.Com publishes the App into the Apps store 
> 2. User buys the App in the App Store (Authentication is requested)
> 3. App is provisioned into the iPhone
> - Client registration
> 4. User runs the App and signUp with Developer.Com (Authentication is requested)
> 5. Developer.Com "Initialize" a Client Registration process with Authorization Server/AM (PKI trust relationship between the parties is requested)
> 6. Authorization Server sends a response to Developer.Com (including AS/metadata and cryptographic data)
> 7. Developer.Com sends an ACK message to App client (including AS/metadata)
> 8. App "Finalize" the client Registration process with the Authorization Server/AM
> 9. App client receives client_id and secret.
> 
> What do you think?
> 
> Domenico
> 
> 
> 
> <PastedGraphic-1.pdf>
> 
> 
> 
> 
> 
> 
> On Jul 23, 2010, at 1:14 AM, Maciej Machulak wrote:
> 
>> Yes, the second one would be a mobile app (WWW being its website). It's just a quick proposal and I'll answer the questions and address comments tomorrow.
>> 
>> Cheers,
>> Maciej
>> 
>>> -----Original Message-----
>>> From: Eve Maler [mailto:eve at xmlgrrl.com]
>>> Sent: 22 July 2010 23:59
>>> To: Maciej Machulak
>>> Cc: WG UMA
>>> Subject: Re: [WG-UMA] OAuth Dynamic Binding - Web App
>>> 
>>> So is the first one a web app and the second one a native app?  I'm not
>>> sure who "WWW" is in the second one.
>>> 
>>> My thinking, at the end of the call, was that we should propose a merged
>>> solution that looks like this:
>>> 
>>> - The server expects all clients to give ("push") it a URL at a minimum,
>>> since this is the minimum required info to share with a user to ensure
>>> authorization is done with the right party and to discover more
>>> metadata.
>>> 
>>> - The client can additionally supply ("push") some portion, or all, of
>>> the other relevant metadata.  [Can we assume that web-app clients
>>> exclusively "push" all necessary metadata, and native-app clients
>>> exclusively "push" only a URL?  This way we don't even need a parameter
>>> to declare the "type" of registration pattern.  I assume this below.]
>>> 
>>> - The metadata supplied ("pushed") by the client could be signed or
>>> unsigned.
>>> 
>>> - If signed, the server retrieves ("pulls") a public key from the
>>> supplied URL in order to validate the signature, having correlated the
>>> domain the client is coming from with the supplied URL.
>>> 
>>> - If only a URL was "pushed", the server returns a random value of the
>>> sort shown in Maciej's diagram, which the native app is required to
>>> stuff into a location on its home server, with additional back-and-forth
>>> as shown...
>>> 
>>> Does this merge the approaches neatly enough?  Is it secure and
>>> efficient enough?
>>> 
>>> 	Eve
>>> 
>>> On 22 Jul 2010, at 3:39 PM, Maciej Machulak wrote:
>>> 
>>>> I've updated the diagram but the provided link still shows the old
>>> version. Take a look at these links then:
>>>> 
>>>> http://tinyurl.com/275w9rx
>>>> http://tinyurl.com/3a8tfmr
>>>> 
>>>> Cheers,
>>>> Maciej
>>>> 
>>>> 
>>>>> -----Original Message-----
>>>>> From: wg-uma-bounces at kantarainitiative.org [mailto:wg-uma-
>>>>> bounces at kantarainitiative.org] On Behalf Of Maciej Machulak
>>>>> Sent: 22 July 2010 23:35
>>>>> To: WG UMA
>>>>> Subject: [WG-UMA] OAuth Dynamic Binding - Web App
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> A sample flow discussed today for dynamic binding could be as
>>> following:
>>>>> 
>>>>> http://tinyurl.com/oauth-binding-web
>>>>> 
>>>>> Cheers,
>>>>> Maciej
>>>>> _______________________________________________
>>>>> WG-UMA mailing list
>>>>> WG-UMA at kantarainitiative.org
>>>>> http://kantarainitiative.org/mailman/listinfo/wg-uma
>>>> _______________________________________________
>>>> WG-UMA mailing list
>>>> WG-UMA at kantarainitiative.org
>>>> http://kantarainitiative.org/mailman/listinfo/wg-uma
>>> 
>>> 
>>> Eve Maler
>>> http://www.xmlgrrl.com/blog
>>> http://www.twitter.com/xmlgrrl
>>> http://www.linkedin.com/in/evemaler
>> 
>> _______________________________________________
>> WG-UMA mailing list
>> WG-UMA at kantarainitiative.org
>> http://kantarainitiative.org/mailman/listinfo/wg-uma
> 
> 
> 
> 
> Domenico Catalano | Identity Architect | +39.335.7257896
> Oracle Fusion Middleware
> via G. Romagnosi - 00142 Rome, Italy
> 
> 	Oracle is committed to developing practices and products that help protect the environment
> 
> 
> 
> 
> 


Eve Maler
http://www.xmlgrrl.com/blog
http://www.twitter.com/xmlgrrl
http://www.linkedin.com/in/evemaler

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-uma/attachments/20100727/39dfd1f0/attachment-0001.html 


More information about the WG-UMA mailing list