> We should solve one problem at a time. It's easy to layer structure > on top of an opaque blob in a separate spec.
+1 to this. Token structure seems like a nice idea, but it's outside what should be dictated by the OAuth spec. We want people to be able to use OAuth to shuttle their existing tokens around, or create hexblobs that mean nothing to anyone else, or encode 37 fields in a structured format that's signed with a private key, or whatever else they want to do, and still have all of that be OAuth. If someone wants to say "we use OAuth and our tokens are UberTokens so they're compatible with everyone else", that's fine; but you should be fully able to do OAuth without adding *any* structure to your tokens whatsoever. -- Justin On Fri, 2010-06-04 at 11:00 -0400, Luke Shepard wrote: > On Jun 4, 2010, at 7:19 AM, George Fletcher wrote: > > > On 6/4/10 9:53 AM, Luke Shepard wrote: > >> > >> Having a single resource server that works with multiple independent auth > >> servers is not in scope for OAuth. That said, there's nothing to stop > >> multiple servers to agree amongst themselves to have a standardized format > >> for access token- and if necessary, to write that agreement as a separate > >> spec (perhaps an extension). > > -1 > > > > limiting OAuth to a single Authorization Server (AS) and it's associated > > SPs (resource owners) significantly restricts the value of delegation > > across the internet. > > > > I'm not saying that we need to limit it just to that circumstance, but the > single-server scenario is one of the most common use cases for OAuth - for > example, Google, Flickr, Facebook, Yahoo, Twitter all generally support > tokens that only work on their own services. I've listed one reason why a > formalized structure would be bad for Facebook (token size would increase). > > We should solve one problem at a time. It's easy to layer structure on top of > an opaque blob in a separate spec. The question to ask is, if a provider > chose NOT to support whatever standardized token format that came up, would > they still be able to use the OAuth 2.0 flows? If the answer is yes, then it > belongs in a different spec. > > > On the other hand, if OAuth allows for cross AS token processing, then it > > becomes very easy for me to protect my photo album while not requiring that > > all those I've shared it with to have an account at my photo service (as > > one example; there are many more). > > There is a lot more that would need to happen to support this outcome than > merely standardizing the format of the token. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
