Hello, I'm working on normalizing Authn Service 1.1 according to Web Resource Authorization Protocol (WRAP) v. 0.9.7.1 But I'd like to discuss Access Token format.
WRAP does not define format of the Access Token, but mentions the Simple Web Token (SWT) like possible Access Token formats (see 6.3, 4.1), btw, higgins already has SAML support, so let compare them. WRAP (4.1) defines the following Access Token requirements: * Protected Resources MUST be able to verify that the Access Token was issued by a trusted Authorization Server and is still valid. * Access Tokens SHOULD periodically expire. * Access Token may be delivered by using HTTP Authorization header or URL parameter or POST parameter. SAML token may be the best choice for WS conversation by using SOAP header. However WRAP assumes to send Access Token by using HTTP header or URL parameter, but the size of all HTTP headers ranging from 4KB to 16KB. SAML is not compact so it may not so good choice to WRAP. We could use SAML without WRAP, when we was going to send Access Token just ones by using POST request, and after that using the Session Token. Simple Web Token is compact and formatted to be easily included in HTTP header. Set of assertions (name/value pairs) should be encoded by using application/x-www-form-urlencoded per 17.13.4 of HTML 4.01. However SWT requires to use SHA 256 HMAC. It assumes that both Auth Service and Protected Service (Attribute Service, CardSync) must know secret HMAC key for calculate/validate HMAC digest, but SWT doesn't define how to distribute HMAC key between all services. Auth service may generate new HMAC key each time, encrypt it by using Protected Service public key and include it in the Access Token. The other option may be using RSA-SHA-256 signature instead of HMAC-SHA-256, but it will be incompatible with SWT. I tend to implement it. Latest WRAP and SWT specifications available at http://groups.google.com/group/oauth-wrap-wg/files . Please let me know your concerns, suggestions. -- thanks, Alexander Yuhimenko On Mon, 9 Nov 2009 15:16:16 +0200 Alexander Yuhimenko <[email protected]> wrote: > 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 > _______________________________________________ higgins-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/higgins-dev
