This sounds like the right approach to handle, either expose a catalog 
that has OAuth config parameters and list of other catalogs and providers 
or use another model to protect the catalog that has the OAuth config 
parameters (like HTTP basic auth).

It is hard to say what the expectation around oauthProvider should be as 
any URL could require some authentication challenge and not limited to 
service provider catalog.  Though it may be worth publishing some best 
practices or implementation guidance on some of these items.

Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645


> From: Ian Green1 <[email protected]>
> To: [email protected]
> Date: 08/26/2010 10:57 AM
> Subject: Re: [oslc-core] Authentication details in service documents
> Sent by: [email protected]
> 
> Hi Jim,
> 
> The DOORS RP OSLC RM implementation does not provide these properties. A 

> provider could offer a top-level catalogue which did not require 
> authentication, but which does not contain security-protected 
information. 
>  This catalog would have an ouathProvider property and a 
> serviceProviderCatalog but no serviceProvider.  My interpretation of the 

> core spec. is that those oauth urls would be used to gain access to the 
> cited serviceProviderCatalog.  This nested catalog would not necessarily 

> contain oauth urls (but it could).
> 
> The IBM Rational Jazz-based providers that I've seen consider the 
catalog 
> to be protected, and the oauth urls come from elsewhere, not defined by 
> OSLC.
> 
> Should the expectation around oauthProvider be clarified, perhaps?
> 
> best wishes,
>     -ian
> 
> [email protected] (Ian Green1/UK/IBM@IBMGB)
> Chief Software Architect, Requirements Definition and Management
> IBM Rational
> 
> [email protected] wrote on 26/08/2010 14:37:17:
> 
> > [image removed] 
> > 
> > [oslc-core] Authentication details in service documents
> > 
> > James Conallen 
> > 
> > to:
> > 
> > oslc-core
> > 
> > 26/08/2010 14:48
> > 
> > Sent by:
> > 
> > [email protected]
> > 
> > As I look at the service documents there are properties for 
> > establishing OAuth in the same document that lists contexts (service
> > providers). I am assuming that documents possessing authentication 
> > establishment information are expected to be available without 
> > authentication. This means that context information will be 
> > available without authentication, which I don't think is right.
> > 
> > What is everyone else's understanding?
> > 
> > <jim/>
> > 
> > jim conallen
> > [email protected]
> > Rational Software, IBM Software Group
> > _______________________________________________
> > Oslc-Core mailing list
> > [email protected]
> > http://open-services.net/mailman/listinfo/oslc-core_open-services.net
> 
> 
> 
> 
> 
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 

> 741598. 
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Oslc-Core mailing list
> [email protected]
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net


Reply via email to