[Openid-specs-ab] Connect Question: Variable "signed" in the response

[John Bradley]

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.

I think that is something that should be rationalized in oAuth 2.0.

John B.
On 2011-01-07, at 4:50 AM, Nat Sakimura wrote:

> In fact, the difference between code and access_token seems to be as follows: 
> 
> code: 
>     applicable endpoint: One Predefined Endpoint Only (token endpoint) 
>     cardinality of the use: Only Once. 
> access_token: 
>     applicable endpoint: Potentially Many Endpoints
>     cardinality of the use: Many. 
> 
> So, "code" in fact is a restricted form of access_token. 
> 
> =nat
> 
> On Thu, Jan 6, 2011 at 4:55 PM, hideki nara <hdknr at ic-tact.co.jp> wrote:
> access_token is enough.
> If the other token format than JWT can be allowed,  we need some way
> to negotiate.
> 
> "code" looks like an artifact. But if tokens are forced to be in
> self-describing forms,  "code" seems to be ok.
> ---
> hdknr
> 
> 2011/1/6 Breno de Medeiros <breno at google.com>:
> > +1
> > Everything about the response content should be signed. It just makes things
> > simpler to process.
> >
> > On Wed, Jan 5, 2011 at 02:40, Nat Sakimura <sakimura at gmail.com> wrote:
> >>
> >> Hi.
> >> The current openidconnect.com page has a variable "signed" in the
> >> response.
> >> It is a new variable which is not present in the current OAuth draft.
> >> The "signed" includes access_token and user_id among other things. It
> >> probably should be a JWT.
> >> Should we continue to use "signed" or other variable name?
> >> The reason why I am asking this are:
> >> 1. It looks a lot like a structured "code" or "access_token". Perhaps
> >> should we call it "access_token" (or "code") instead?
> >> 2. If we are to introduce a new variable, "signed" seem to be a little too
> >> generic. Is there a better name for it? (Perhaps "openid"?)
> >>
> >> --
> >> Nat Sakimura (=nat)
> >> http://www.sakimura.org/en/
> >> http://twitter.com/_nat_en
> >>
> >> _______________________________________________
> >> Openid-specs-ab mailing list
> >> Openid-specs-ab at lists.openid.net
> >> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> >>
> >
> >
> >
> > --
> > --Breno
> >
> > _______________________________________________
> > Openid-specs-ab mailing list
> > Openid-specs-ab at lists.openid.net
> > http://lists.openid.net/mailman/listinfo/openid-specs-ab
> >
> >
> 
> 
> 
> -- 
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
> http://twitter.com/_nat_en
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110107/3651e611/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110107/3651e611/attachment.p7s>