Thanks Tom, I'd like to update Auth Service 1.1 according to WRAP '5.3 Username and Password Profile'.
We have to add the following changes: * use 'application/x-www-form-urlencoded' format for encoding request/response parameters (Auth Service supports XML and Protobuf); * use SWT format for Access Token instead of SAML due to limited http header size, it's usually 8k-16k, but tomcat default is just 4k; * use Access Token instead of Session Token, so doesn't use Seesion token at all; * add refresh Access Token method according to 5.3.7 - 5.3.9; * update request Access Token method according to 5.3.3 - 5.3.6. Paul, Valery are you agree? However, WRAP doesn't define API for provisioning and updating user account, so we may leave it as is (using XML/Protobuf), or redefine it in WRAP way? -- thanks, Alexander Yuhimenko On Thu, 5 Nov 2009 20:43:49 -0800 Tom Carroll <[email protected]> wrote: > Today I saw the WRAP protocol [1] presented at IIW. WRAP is a proposed new > version of OAuth that separates the authentication service from the protected > resource. If you take a look at WRAP's "username-password" profile, it looks > incredibly similar to our Auth Service 1.1. It even contemplates that the > client would have been provisioned with a unique identifier (eg 'serialized > selector'), but doesn't get into the details of how this would happen, since > the protect resource doesn't need to know anything about that. > > One difference I see is that in Higgins Authn Svc 1.1, the Access Token (AT) > is exchanged for a Session Token at the protected resource, while in WRAP, > the AT is sent with every request, and the protected resource just responds. > There is no session - it is stateless. Other than that, it seems virtually > identical, just a matter of naming conventions. > > Anyway, I was thinking that it might make sense to normalize the Authn > Service 1.1 protocol to match a profile of the WRAP protocol, or perhaps > suggest tweaks or a new profile to WRAP that fits our needs if the un/pw > profile doesn't quite fit. It would be good to take a broader community > approach, rather than a Higgins-only approach. > > [1] http://groups.google.com/group/WRAP-WG > > _______________________________________________ higgins-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/higgins-dev
