I can see different security requirements requiring different encryption.
In a LoA 3 situation using a asymmetric key may be a requirement. The Key value token format is simple to process but has limitations. It may be that using a structured Simple Web Token, JASON Web Token or XML format may work better in some applications. I thought it was you that raised the Jason formatted token idea. I don't necessarily want to define a bunch of token types now. I do however think we should plan for it if it is something we will want to do later. I do think that there needs to be a symmetrically or asymmetrically encrypted token type. The alternatives to make openID LoA 2+ are much more painful. John B. On 2010-02-08, at 10:51 PM, Nat Sakimura wrote: > If the usecase is real, I am all for it, but I am not sure why RP wants to > have a specific type of OP token. Could you elaborate a little more? > > =nat > > P.S., since we are talking about use cases etc., I am assuming it is still > safe to do this at s...@. > > On Tue, Feb 9, 2010 at 10:22 AM, John Bradley <[email protected]> wrote: > I wasn't referring to the artifact itself. I agree that should be opaque. > > I am talking about the token that is returned from the direct communication. > > That needs to be encrypted. > > Encrypting it with the symmetric key works as a basic option. > > The RP needs some way to signal the OP what token type it wants to get. > > EG plain, plane + symetric, plane + asymetric, jason + asymetric etc. > > I don't know that overloading PAPE is the best thing. > > John B. > > > On 2010-02-08, at 10:14 PM, Nat Sakimura wrote: > >> I changed the Subject to fit the discussion. >> >> It is not me who decides what but the WG so this is just my personal >> opinion, >> but to me, Artifact is an opaque string to the RP. i.e., it can be anything, >> and it does not matter. >> It is up to the OP to create and consume artifact. Only requirement in the >> contributed >> document is that it has to be constructed partly from RFC1750 pseudorandom >> number sequence >> to thwart guessing. Since it is OP who creates and consume it, the OP can >> encrypt it by >> his symmetric key. >> >> If you wanted to express whether it was encrypted or not, there are two ways >> of doing it, IMHO. >> >> One is as you suggested, to do it in the AB itself. In this case, I would >> support the idea of >> arbitrary token types. >> >> The other is to do it through PAPE. >> >> If it were just for LoA, I feel that keeping the Artifact completely opaque >> and >> using PAPE for LoA purpose is the right way to do. >> >> =nat >> >> (2010/02/08 23:59), John Bradley wrote: >>> >>> The Artifact binding will have to support a encrypted token type or types >>> if it is going to be LoA 2+ compliant. >>> >>> The question is if you are going to support 2 token types, should it be >>> generalized to support arbitrary token types. >>> >>> John B. >>> On 2010-02-08, at 8:16 AM, Nat Sakimura wrote: >>> >>>> Hmmm. OK. Got it. >>>> >>>> So, it probably is the topic that we might want to revisit when we >>>> introduce new response type like JSON in v.next, if we ever do, I suppose. >>>> There may be some cases that we might want to respond to the request at >>>> once. (Do not know if there would be.) >>>> >>>> Thanks. >>>> >>>> =nat >>>> >>>> On Mon, Feb 8, 2010 at 3:03 PM, Will Norris <[email protected]> wrote: >>>> >>>> On Feb 7, 2010, at 8:45 PM, Nat Sakimura wrote: >>>> >>>> > (2010/02/08 10:50), Will Norris wrote: >>>> >> I've never thought of the "openid." prefix as part of the parameter >>>> >> name, even in URL form encoded messages... it's simply a namespace >>>> >> prefix to ensure URL parameters don't collide. It's completely >>>> >> unnecessary in KVF encoded messages, and would add nothing but extra >>>> >> size to the payload. >>>> > >>>> > That's what I was thinking. But after Hideki's message, I started to >>>> > doubt that a bit. >>>> > Currently, we only use Direct Response in a very limited way: (1) >>>> > association response and (2) direct verification. In both case, we >>>> > actually only send openid.* parameters in the request, so we do not need >>>> > any name space qualifier in the response. >>>> >>>> Not necessarily. What about when the OpenID server's URL is >>>> "http://example.com/?service=openid"; ? This was actually the case for the >>>> WordPress OpenID plugin for a long time, and is still true for certain >>>> deployments, I believe. You can't make any assumptions about what the >>>> base URL will be, or what additional parameters may be present, hence why >>>> the "openid." is certainly necessary in those cases. >>>> >>>> >>>> > If we do not send anything but openid parameters on the request, >>>> > openid.* as a part of url is redundant. >>>> > If there is value in having openid.* in the request, then that is to >>>> > send parameters in other name-spaces, in which case, the response may >>>> > include other parameters as well, and we need name-space qualifier. >>>> >>>> allowing non-OpenID parameters in a direct response has never been a >>>> design goal, nor do I believe that it should be. KVF encoding is a new >>>> format defined by the OpenID spec, so it is perfectly acceptable to state >>>> that it is only for OpenID related parameters. This is not the case for >>>> URL parameters. >>>> _______________________________________________ >>>> specs mailing list >>>> [email protected] >>>> http://lists.openid.net/mailman/listinfo/openid-specs >>>> >>>> >>>> >>>> -- >>>> Nat Sakimura (=nat) >>>> http://www.sakimura.org/en/ >>>> http://twitter.com/_nat_en >>>> _______________________________________________ >>>> specs mailing list >>>> [email protected] >>>> http://lists.openid.net/mailman/listinfo/openid-specs >>> >>> _______________________________________________ >>> specs mailing list >>> [email protected] >>> http://lists.openid.net/mailman/listinfo/openid-specs >>> >> >> >> -- >> Nat Sakimura ([email protected]) >> Nomura Research Institute, Ltd. >> Tel:+81-3-6274-1412 Fax:+81-3-6274-1547 >> _______________________________________________ >> specs mailing list >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-specs > > > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs > > > > > -- > Nat Sakimura (=nat) > http://www.sakimura.org/en/ > http://twitter.com/_nat_en
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
