> -----Original Message----- > From: Marius Scurtescu [mailto:mscurte...@google.com] > Sent: Monday, April 19, 2010 1:50 PM
> How does defining the scope structure help interop? Clients can use scopes the same way across provides and don't need to read paperwork to figure out how to use the parameter. It allows smooth and seamless interaction with an unfamiliar server using an open API format. > There was a good argument why not define it. Getting everyone to agree on > one definition can be hard, and you cannot be sure everyone was consulted. > There are lots of service providers out there that use scopes today. Are we > sure that a space separated list of URIs will work for all of them? Everything is hard to agree on - welcome to the wonderful work of standards. The signatures discussion took months for example. But you can't make this argument without even trying. Let's spend a week discussing a proposal (or others if people want to submit more) and see where we end up. As for those not participating, well, that's their problem. Seriously, if you don't bother to show up and participate you have absolutely no say. Specs are created by those who show up. > When you wanted to leave scopes out altogether, you wanted proof they > are needed :-) That wasn't my position. My position was that the parameter was underspecified and as such added no value. I tried repeatedly to discuss ideas on how to define it but you and others just shot me down every time arguing it must be vendor-specific. > I did a proof of concept implementation, with client, server and protected > resource support libraries, and the scope structure was never an issue. > Actual client, server and resource code, does need to deal with scopes, but > this is not the generic code that would go into a library. Did your library handle unknown parameters, passing them through the call stack? > I do agree that it would be nice to have a defined structure for scopes, I > just > don't think it is that important and that it is hard to get right. I disagree on both. It is important and not so hard to get right, just like any other feature we decide to include. How would you know if we don't even try? This exact argument was made 3 years ago. Dick Hardt asked for a scope parameter. As editor I added a generic scope parameter to the spec called oauth_token_attributes. However the group consensus was that it was underspecified and lacked any implementation experience. We drop it and decided to revisit in an extension. That never happened. Instead, each vendor made up their own parameter. We are back where we started now, with the same arguments. I think 3 years is plenty experience to get this done right. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
