SWT 0.9.4.1
Brian Eaton
> Comments and suggestions welcome!
Why not use SAML?
Why not use OpenToken?
Why not use XML for serialization?
Why not use JSON for serialization?
Why not use ASN.1 for serialization?
Can these tokens be designed so that the wire format uses only
alphanumerics so that passing them around through query
strings/urls/headers/xml/json/etc... does not modify the value? Maybe
use the URL safe base64 alphabet from
http://www.faqs.org/rfcs/rfc3548.html, along with a caveat that the
token must not include line breaks or padding? (RFC 3548 section 2
allows both of those rules.)
Can we better define semantics for Issuer and Audience? How should
Issuer values be chosen? How should Audience values be chosen?
Cheers,
Brian
Dick Hardt
> -----Original Message-----
> From: WRA...@googlegroups.com [mailto:WRA...@googlegroups.com] On
> Behalf Of Brian Eaton
> Sent: Wednesday, October 21, 2009 11:50 AM
> To: WRA...@googlegroups.com
> Subject: [WRAP] Re: SWT 0.9.4.1
>
>
> On Mon, Oct 19, 2009 at 4:42 PM, Dick Hardt <Dick....@microsoft.com>
> wrote:
> > Comments and suggestions welcome!
>
> Why not use SAML?
Too big for headers
> Why not use OpenToken?
>
> Why not use XML for serialization?
>
> Why not use JSON for serialization?
>
> Why not use ASN.1 for serialization?
When just needing name/value pairs, application/x-www-form-urlencoded is a well understood serialization format that does not require a library to parse.
Are you suggesting the document should explain that better, or are you disagreeing with the choice?
>
> Can these tokens be designed so that the wire format uses only
> alphanumerics so that passing them around through query
> strings/urls/headers/xml/json/etc... does not modify the value? Maybe
> use the URL safe base64 alphabet from
> http://www.faqs.org/rfcs/rfc3548.html, along with a caveat that the
> token must not include line breaks or padding? (RFC 3548 section 2
> allows both of those rules.)
I think that is why we are talking about JSON Web Tokens as another format, and encoding in URL safe base 64. It does require a JSON parser.
> Can we better define semantics for Issuer and Audience?
What is unclear in the semantics? Issuer is who issued the token, Audience is who the token is intended for.
> How should Issuer values be chosen? How should Audience values be chosen?
What would you suggest? URIs or hostnames make the most sense as a suggestion in the spec.
-- Dick
Brian Eaton
> When just needing name/value pairs, application/x-www-form-urlencoded is a well
> understood serialization format that does not require a library to parse.
>
> Are you suggesting the document should explain that better, or are you disagreeing with the choice?
After giving it some thought, I'm disagreeing with the choice. I've
got a few particular objections:
1) form-urlencoded uses lots of characters that are prone to
corruption/escaping in different contexts. If we expect these tokens
to be used a lot, they are going to get passed around through lots of
different systems. We should take the time now to make sure that all
kinds of code can treat these tokens as opaque values. That would
mean sticking with a very restricted subset of characters for the wire
format.
2) form-urlencoded looks simple until you try to do things like pass a
list of values, or even a hierarchical data type. For example, how do
you pass a list of group memberships for a user? How about the user's
last authentication time? How do you do it if there are multiple
users involved in the request? What if the user has an e-mail, an
openid, and an opaque identifier, and you need to pass all of them?
> I think that is why we are talking about JSON Web Tokens as another format, and encoding in URL safe base 64. It does require a JSON parser.
I think we should skip SWT entirely. =) It is going to seem very,
very limiting in short-order.
>> Can we better define semantics for Issuer and Audience?
>
> What is unclear in the semantics? Issuer is who issued the token, Audience is who the token is intended for.
>
>> How should Issuer values be chosen? How should Audience values be chosen?
>
> What would you suggest? URIs or hostnames make the most sense as a suggestion in the spec.
Absolute URI for issuer seem like a good idea to me.
I'm a little fuzzy on how to handle audience. Let's say that audience
X shows up in a request for URL Y. How do we detect whether X is an
appropriate audience for Y?
Note that in OAuth this is implicit: the entire URL + query string +
some post parameters is sufficient to identify audience.
Cheers,
Brian
Brian Eaton
ExpiresOn may not be sufficient as a timestamp. We probably want
either IssuedOn, or a combination of NotBefore and NotAfter.
Imagine a case where one system wants to generate a ticket good for
the next 60 seconds. However, due to a misconfiguration, the clock on
that machine is set far into the future. The generated ExpiresOn
value will be far into the future as well.
Receiving machines will happily accept the tokens; they have no way of
detecting that clock skew has gone beyond acceptable levels.
IssuedOn: this is nice, because it is a statement of fact rather than
opinion. One system can decide that tickets can be up to ten minutes
old, another can decide that an hour is OK, but they can both make
that calculation based on the IssuedOn timestamp.
NotBefore and NotAfter: also nice, because it lets you have built-in
expiration dates.
Cheers,
Brian
Dick Hardt
> From: WRA...@googlegroups.com [mailto:WRA...@googlegroups.com] On
> Behalf Of Brian Eaton
> Sent: Thursday, October 22, 2009 2:14 PM
> To: WRA...@googlegroups.com
> Subject: [WRAP] Re: SWT 0.9.4.1
>
>
> wrote:
> > When just needing name/value pairs, application/x-www-form-urlencoded
> is a well
> > understood serialization format that does not require a library to
> parse.
> >
> > Are you suggesting the document should explain that better, or are
> you disagreeing with the choice?
>
> After giving it some thought, I'm disagreeing with the choice. I've
> got a few particular objections:
>
> 1) form-urlencoded uses lots of characters that are prone to
> corruption/escaping in different contexts. If we expect these tokens
> to be used a lot, they are going to get passed around through lots of
> different systems. We should take the time now to make sure that all
> kinds of code can treat these tokens as opaque values. That would
> mean sticking with a very restricted subset of characters for the wire
> format.
>
> 2) form-urlencoded looks simple until you try to do things like pass a
> list of values, or even a hierarchical data type. For example, how do
> you pass a list of group memberships for a user? How about the user's
> last authentication time? How do you do it if there are multiple
> users involved in the request? What if the user has an e-mail, an
> openid, and an opaque identifier, and you need to pass all of them?
Valid comments. That is why we are also working on JSON Web Tokens! :-)
>
> > I think that is why we are talking about JSON Web Tokens as another
> format, and encoding in URL safe base 64. It does require a JSON
> parser.
>
> I think we should skip SWT entirely. =) It is going to seem very,
> very limiting in short-order.
Coming from the Perl world, more than one way to do it seems like a good approach for now. :-)
>
> >> Can we better define semantics for Issuer and Audience?
> >
> > What is unclear in the semantics? Issuer is who issued the token,
> Audience is who the token is intended for.
> >
> >> How should Issuer values be chosen? How should Audience values be
> chosen?
> >
> > What would you suggest? URIs or hostnames make the most sense as a
> suggestion in the spec.
>
> Absolute URI for issuer seem like a good idea to me.
>
> I'm a little fuzzy on how to handle audience. Let's say that audience
> X shows up in a request for URL Y. How do we detect whether X is an
> appropriate audience for Y?
URL Y knows what claims are valid for it. This of course leads to some discovery on how the Client can determine what claims it needs from the Authorization Server so that it can access a given Protected Resource, but that would be another spec. =)
>
> Note that in OAuth this is implicit: the entire URL + query string +
> some post parameters is sufficient to identify audience.
Depends on how you define audience =)
Dick Hardt
> -----Original Message-----
> From: WRA...@googlegroups.com [mailto:WRA...@googlegroups.com] On
> Behalf Of Brian Eaton
> Sent: Thursday, October 22, 2009 2:22 PM
> To: WRA...@googlegroups.com
> Subject: [WRAP] Re: SWT 0.9.4.1
>
>