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
