<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Sending the identifier through the browser only works for low assurance cases eg LoA 1. <div><br></div><div>It however was one of the features of Connect. </div><div><br></div><div>I am not personally attached to it as it causes a bunch of problems.</div><div><br></div><div>In session synchronization calls any mutually agreed session identifier should work. I don't think it necessarily needs to be the userID though that may be more convenient in some circumstances.</div><div><br></div><div>It is almost better to have a clearly separate session identifier on a per RP basis for the user. That may make adding SLO easier in future.</div><div><br></div><div>John B.<br><div><div>On 2011-01-07, at 2:12 PM, Breno de Medeiros wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br><br><div class="gmail_quote">On Fri, Jan 7, 2011 at 08:58, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word">I thought part of the use case was that the RP could directly verify the signed response and get the user ID without making a second call if they are pre-registerd and don't need additional info?</div>
</blockquote><div><br></div><div>I think this is crucial in frequent session synchronization-like calls to ensure the user is still logged in at the provider, but not as essential in initial login (by which I mean there's no session at the RP). </div>
<div><br></div><div>Sending the identifier through the browser adds a fair amount of complexity.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word">
<div><br></div><div>So the user ID needs to be there in some signed portion.</div><div><br></div><div>I suppose we could send a JWT that included code but that seems like duplication.</div><div><br></div><div>John B.<div>
<div></div><div class="h5"><br><div><div>On 2011-01-07, at 1:41 PM, Nat Sakimura wrote:</div><br><blockquote type="cite">Well, the initial token sounds like a "code". <div><br></div><div>I prefer opaque "code" to the b64url encoded combination of user_id etc., as it has a chance of leaking the information unnecessarily. </div>
<div><br></div><div>So, to paraphrase, the question is whether the User Authorization Endpoint should return the "code" or more information, I suppose. I prefer "code" approach, but I am probably biased as that is how things were done in AB drafts up to now. </div>
<div><br></div><div>=nat<br><br><div class="gmail_quote">On Sat, Jan 8, 2011 at 1:00 AM, Breno de Medeiros <span dir="ltr"><<a href="mailto:breno@google.com" target="_blank">breno@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There's an alternative proposal (I just made in another thread) to simply do away with the token-in-token and also how to encode a token in the response.<div><br></div><div>The proposal is to return a regular OAuth2 token and a standard OAuth2 response. The token is opaque, not JWT.</div>
<div><br></div><div>The UserInfo endpoint would return both plaintext user data and a signed JWT token including a subset of the user information that can be used as a cookie.</div><div><br></div><div>This adds a round-trip to initial sign-in, but subsequent 'pings' for confirmation of session presence can be made directly to the UserInfoEndpoint, using the access token as before.</div>
<div><br></div><div>This approach works identically for WebServer and UserAgent flows. In both cases, the UserInfo endpoint is a standard OAuth2-protected resource, with a set of specified fields it must return (including signed JWT).</div>
<div><br></div><div>What do you think about this?</div><div><div></div><div><div><br></div><div><br><div class="gmail_quote">On Fri, Jan 7, 2011 at 07:39, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Yes I think it is a restricted form of access token. The main difference is that you can require a shared secret to be sent with code, where there seems to be no oAuth 2.0 way to do the same with an access token.<div>
<br></div><div>I think that is something that should be rationalized in oAuth 2.0.</div><div><br></div><div>John B.<div><div></div><div><br><div><div>On 2011-01-07, at 4:50 AM, Nat Sakimura wrote:</div><br><blockquote type="cite">
In fact, the difference between code and access_token seems to be as follows: <div><br></div><div>code: </div><div> applicable endpoint: One Predefined Endpoint Only (token endpoint) </div><div> cardinality of the use: Only Once. </div>
<div>access_token: </div><div> applicable endpoint: Potentially Many Endpoints</div><div> cardinality of the use: Many. </div><div><br></div><div>So, "code" in fact is a restricted form of access_token. </div>
<div><br></div><div>=nat<br><br><div class="gmail_quote">On Thu, Jan 6, 2011 at 4:55 PM, hideki nara <span dir="ltr"><<a href="mailto:hdknr@ic-tact.co.jp" target="_blank">hdknr@ic-tact.co.jp</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
access_token is enough.<br>
If the other token format than JWT can be allowed, we need some way<br>
to negotiate.<br>
<br>
"code" looks like an artifact. But if tokens are forced to be in<br>
self-describing forms, "code" seems to be ok.<br>
---<br>
hdknr<br>
<br>
2011/1/6 Breno de Medeiros <<a href="mailto:breno@google.com" target="_blank">breno@google.com</a>>:<br>
<div><div></div><div>> +1<br>
> Everything about the response content should be signed. It just makes things<br>
> simpler to process.<br>
><br>
> On Wed, Jan 5, 2011 at 02:40, Nat Sakimura <<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>> wrote:<br>
>><br>
>> Hi.<br>
>> The current <a href="http://openidconnect.com/" target="_blank">openidconnect.com</a> page has a variable "signed" in the<br>
>> response.<br>
>> It is a new variable which is not present in the current OAuth draft.<br>
>> The "signed" includes access_token and user_id among other things. It<br>
>> probably should be a JWT.<br>
>> Should we continue to use "signed" or other variable name?<br>
>> The reason why I am asking this are:<br>
>> 1. It looks a lot like a structured "code" or "access_token". Perhaps<br>
>> should we call it "access_token" (or "code") instead?<br>
>> 2. If we are to introduce a new variable, "signed" seem to be a little too<br>
>> generic. Is there a better name for it? (Perhaps "openid"?)<br>
>><br>
>> --<br>
>> Nat Sakimura (=nat)<br>
>> <a href="http://www.sakimura.org/en/" target="_blank">http://www.sakimura.org/en/</a><br>
>> <a href="http://twitter.com/_nat_en" target="_blank">http://twitter.com/_nat_en</a><br>
>><br>
>> _______________________________________________<br>
>> Openid-specs-ab mailing list<br>
>> <a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
>> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
>><br>
><br>
><br>
><br>
> --<br>
> --Breno<br>
><br>
> _______________________________________________<br>
> Openid-specs-ab mailing list<br>
> <a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
><br>
><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/" target="_blank">http://www.sakimura.org/en/</a><br><a href="http://twitter.com/_nat_en" target="_blank">http://twitter.com/_nat_en</a><br>
</div>
_______________________________________________<br>Openid-specs-ab mailing list<br><a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div><br></div></div></div></div><br>_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>--Breno<br>
</div>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/" target="_blank">http://www.sakimura.org/en/</a><br><a href="http://twitter.com/_nat_en" target="_blank">http://twitter.com/_nat_en</a><br>
</div>
</blockquote></div><br></div></div></div></div></blockquote></div><br><br clear="all"><br>-- <br>--Breno<br>
</blockquote></div><br></div></body></html>