Related to this, in UMA we chose "Host" for the online service where a protected resource can be accessed, because each resource found there might potentially be subject to a different user-managed authorization policy (that is, protection) regime. We've found this word to be quite copacetic, as it's short and intuitive, has a unique single-letter abbreviation, and doesn't imply that the service is the same thing as a particular resource available at the service.
At first, we tried to stick with "SP" for this entity -- this was before the server/client terminology emerged in the OAuth 1.0 cleanup effort -- but found it to be too confusing because the Host has an OAuth-mediated relationship with the UMA Authorization Manager (note, not the same thing as a WRAP Authorization Server!) that is consumer->SP / client->server. I wonder if "Host" can work in the context of the WRAP patterns too, since all the same things are true about this word in both contexts... BTW, here's a direct link to the UMA terminology section: http://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protocol#UMA1.0CoreProtocol-Terminology Eve On 2 Feb 2010, at 2:41 PM, Peter Saint-Andre wrote: > On 2/2/10 3:12 PM, Dick Hardt wrote: >> >> On 2010-02-02, at 2:08 PM, Peter Saint-Andre wrote: >>> On 1/28/10 11:35 PM, David Recordon wrote: >>>> I have a pretty strong preference of sticking with OAuth 1.0 >>>> terminology as much as possible. >>> >>> Agreed. >> >> The term "server" in OAuth 1.0 does not differentiate between the >> Authorization Server and Protected Resource as are differentiated in >> OAuth WRAP. >> >> The terms used in OAuth WRAP are a superset of OAuth 1.0 with changes >> to provide additional clarity. > > I meant to say "agreed, where possible and reasonable". The point of > this exercise is to make sure that we differentiate where that makes > sense. :) > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ Eve Maler [email protected] http://www.xmlgrrl.com/blog _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
