Re: [OAUTH-WG] OAuth Signature Draft Pre 00
Nat had reviewed Yaron's and my proposal and encouraged us to proceed with it. Yes, it's intentionally general and not OAuth specific (just like SWTs were). The JWT token type will have uses outside OAuth. Dirk and we agree that we need to come up with a unified JSON token spec. Later today I'll write up a set of comments on the differences between Dirk's proposal and the JWT one as they stand today to kick-start the discussions of specifics. Cheers, -- Mike From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of David Recordon Sent: Monday, September 27, 2010 9:24 AM To: Anthony Nadalin Cc: oauth Subject: Re: [OAUTH-WG] OAuth Signature Draft Pre 00 Mike and Yaron's proposal is different from Nat's though. Nat's is based directly around OAuth versus explicitly defining a separate signing mechanism and then a second spec to map it into OAuth. It also supports fewer options (no unsigned tokens for example) which makes it easier to understand within this context. Dirk's now seems to be four specs which then reference Magic Signatures for the underlying signing. On Mon, Sep 27, 2010 at 9:17 AM, Anthony Nadalin mailto:tony...@microsoft.com>> wrote: So we have been working with Nat on the signature proposal and talking to Nat he agrees that the JWT proposal is well under way, what I would like to make sure is that we merged in with your proposal From: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org> [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On Behalf Of Dirk Balfanz Sent: Monday, September 27, 2010 9:13 AM To: David Recordon Cc: oauth Subject: Re: [OAUTH-WG] OAuth Signature Draft Pre 00 I'm just as confused :-) I think what happened is that I posted a signature draft and then didn't follow up. Nat then very kindly agreed to help and put out a draft, but that also didn't get much momentum. So I went back and re-did my drafts. Also, somewhere along the way, Yoran wrote a draft. At least that's what it looks like from where I'm sitting. I might be getting it wrong (maybe Yoran's draft represents a merge of his and Nat's thinking? - I'm not sure). At any rate, of course we need to end up with one proposal in the end. I'm fairly agnostic about the details, but I believe the following should be true about any merged proposal: - very limited number of options for signature algorithms, key representations (should not require more than 10..20 lines of code in your given platform, without any additional library, to implement signature and key parsing). - must support both public and symmetric keys. - should not have security flaws Dirk. On Mon, Sep 27, 2010 at 6:59 AM, David Recordon mailto:record...@gmail.com>> wrote: I'm a bit confused between the relationship of Nat's I-D and the documents you and Mike recently posted. Is the goal to have one I-D? Nat's seems to have fewer options and different modes which makes it easier to read and understand. On Mon, Aug 30, 2010 at 11:47 AM, Yaron Goland mailto:yar...@microsoft.com>> wrote: BTW, Nat and I, as mentioned below, are talking. Here is my current draft. Please keep in mind that it's really just a set of notes trying to capture all the issues involved in creating a secure token format so it's a bit dense. My hope is that once all the issues are captured it can be completely re-written to be in something that looks more like English and is easier for actual implementers to follow. But for now I think it gives a good sense of the some of the security challenges in creating a secure token format. Yaron From: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org> [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On Behalf Of Nat Sakimura Sent: Tuesday, August 24, 2010 6:50 AM To: oauth Subject: [OAUTH-WG] OAuth Signature Draft Pre 00 Hi. It has been a few weeks since then I volunteered to do this work. I have written up to this pre 00 draft then have been doing some reality checks on some script languages etc. No. This pre-00 draft is far from being feature complete. I still need to copy and paste the Magic Signatures text etc. Also, I should add how this spec is being used in some of the major flows. However, since I will not be able to work on it this week, I thought it would be worthwhile to share this early draft so that you have some clarity into the progress. Apparently, Yaron has been working on it as well. We will compare the notes and try to merge, I hope. So, here it is! #For those of you who have seen the private draft, it has not been changed since July 31. Best, =nat ___ OAuth mailing list OAuth@ietf.or
Re: [OAUTH-WG] OAuth Signature Draft Pre 00
Mike and Yaron's proposal is different from Nat's though. Nat's is based directly around OAuth versus explicitly defining a separate signing mechanism and then a second spec to map it into OAuth. It also supports fewer options (no unsigned tokens for example) which makes it easier to understand within this context. Dirk's now seems to be four specs which then reference Magic Signatures for the underlying signing. On Mon, Sep 27, 2010 at 9:17 AM, Anthony Nadalin wrote: > So we have been working with Nat on the signature proposal and talking to > Nat he agrees that the JWT proposal is well under way, what I would like to > make sure is that we merged in with your proposal > > > > *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf > Of *Dirk Balfanz > *Sent:* Monday, September 27, 2010 9:13 AM > *To:* David Recordon > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] OAuth Signature Draft Pre 00 > > > > I'm just as confused :-) I think what happened is that I posted a signature > draft and then didn't follow up. Nat then very kindly agreed to help and put > out a draft, but that also didn't get much momentum. So I went back and > re-did my drafts. Also, somewhere along the way, Yoran wrote a draft. At > least that's what it looks like from where I'm sitting. I might be getting > it wrong (maybe Yoran's draft represents a merge of his and Nat's thinking? > - I'm not sure). > > > > At any rate, of course we need to end up with one proposal in the end. I'm > fairly agnostic about the details, but I believe the following should be > true about any merged proposal: > > > > - very limited number of options for signature algorithms, key > representations (should not require more than 10..20 lines of code in your > given platform, without any additional library, to implement signature and > key parsing). > > - must support both public and symmetric keys. > > - should not have security flaws > > > Dirk. > > On Mon, Sep 27, 2010 at 6:59 AM, David Recordon > wrote: > > I'm a bit confused between the relationship of Nat's I-D and the documents > you and Mike recently posted. Is the goal to have one I-D? Nat's seems to > have fewer options and different modes which makes it easier to read and > understand. > > > > On Mon, Aug 30, 2010 at 11:47 AM, Yaron Goland > wrote: > > BTW, Nat and I, as mentioned below, are talking. Here is my current > draft. Please keep in mind that it's really just a set of notes trying to > capture all the issues involved in creating a secure token format so it's a > bit dense. My hope is that once all the issues are captured it can be > completely re-written to be in something that looks more like English and is > easier for actual implementers to follow. But for now I think it gives a > good sense of the some of the security challenges in creating a secure token > format. > > Yaron > > > > *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf > Of *Nat Sakimura > *Sent:* Tuesday, August 24, 2010 6:50 AM > *To:* oauth > *Subject:* [OAUTH-WG] OAuth Signature Draft Pre 00 > > > > Hi. > > > > It has been a few weeks since then I volunteered to do this work. > > I have written up to this pre 00 draft then have been doing some reality > checks on some script languages etc. > > > > No. This pre-00 draft is far from being feature complete. > > I still need to copy and paste the Magic Signatures text etc. > > Also, I should add how this spec is being used in some of the major flows. > > > > However, since I will not be able to work on it this week, I thought it > would be worthwhile to share this early draft so that you have some clarity > into the progress. > > > > Apparently, Yaron has been working on it as well. We will compare the notes > and try to merge, I hope. > > > > So, here it is! > > > > #For those of you who have seen the private draft, it has not been changed > since July 31. > > > > Best, > > > > =nat > > > > > > > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Signature Draft Pre 00
So we have been working with Nat on the signature proposal and talking to Nat he agrees that the JWT proposal is well under way, what I would like to make sure is that we merged in with your proposal From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Dirk Balfanz Sent: Monday, September 27, 2010 9:13 AM To: David Recordon Cc: oauth Subject: Re: [OAUTH-WG] OAuth Signature Draft Pre 00 I'm just as confused :-) I think what happened is that I posted a signature draft and then didn't follow up. Nat then very kindly agreed to help and put out a draft, but that also didn't get much momentum. So I went back and re-did my drafts. Also, somewhere along the way, Yoran wrote a draft. At least that's what it looks like from where I'm sitting. I might be getting it wrong (maybe Yoran's draft represents a merge of his and Nat's thinking? - I'm not sure). At any rate, of course we need to end up with one proposal in the end. I'm fairly agnostic about the details, but I believe the following should be true about any merged proposal: - very limited number of options for signature algorithms, key representations (should not require more than 10..20 lines of code in your given platform, without any additional library, to implement signature and key parsing). - must support both public and symmetric keys. - should not have security flaws Dirk. On Mon, Sep 27, 2010 at 6:59 AM, David Recordon mailto:record...@gmail.com>> wrote: I'm a bit confused between the relationship of Nat's I-D and the documents you and Mike recently posted. Is the goal to have one I-D? Nat's seems to have fewer options and different modes which makes it easier to read and understand. On Mon, Aug 30, 2010 at 11:47 AM, Yaron Goland mailto:yar...@microsoft.com>> wrote: BTW, Nat and I, as mentioned below, are talking. Here is my current draft. Please keep in mind that it's really just a set of notes trying to capture all the issues involved in creating a secure token format so it's a bit dense. My hope is that once all the issues are captured it can be completely re-written to be in something that looks more like English and is easier for actual implementers to follow. But for now I think it gives a good sense of the some of the security challenges in creating a secure token format. Yaron From: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org> [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On Behalf Of Nat Sakimura Sent: Tuesday, August 24, 2010 6:50 AM To: oauth Subject: [OAUTH-WG] OAuth Signature Draft Pre 00 Hi. It has been a few weeks since then I volunteered to do this work. I have written up to this pre 00 draft then have been doing some reality checks on some script languages etc. No. This pre-00 draft is far from being feature complete. I still need to copy and paste the Magic Signatures text etc. Also, I should add how this spec is being used in some of the major flows. However, since I will not be able to work on it this week, I thought it would be worthwhile to share this early draft so that you have some clarity into the progress. Apparently, Yaron has been working on it as well. We will compare the notes and try to merge, I hope. So, here it is! #For those of you who have seen the private draft, it has not been changed since July 31. Best, =nat ___ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Signature Draft Pre 00
I'm just as confused :-) I think what happened is that I posted a signature draft and then didn't follow up. Nat then very kindly agreed to help and put out a draft, but that also didn't get much momentum. So I went back and re-did my drafts. Also, somewhere along the way, Yoran wrote a draft. At least that's what it looks like from where I'm sitting. I might be getting it wrong (maybe Yoran's draft represents a merge of his and Nat's thinking? - I'm not sure). At any rate, of course we need to end up with one proposal in the end. I'm fairly agnostic about the details, but I believe the following should be true about any merged proposal: - very limited number of options for signature algorithms, key representations (should not require more than 10..20 lines of code in your given platform, without any additional library, to implement signature and key parsing). - must support both public and symmetric keys. - should not have security flaws Dirk. On Mon, Sep 27, 2010 at 6:59 AM, David Recordon wrote: > I'm a bit confused between the relationship of Nat's I-D and the documents > you and Mike recently posted. Is the goal to have one I-D? Nat's seems to > have fewer options and different modes which makes it easier to read and > understand. > > > On Mon, Aug 30, 2010 at 11:47 AM, Yaron Goland wrote: > >> BTW, Nat and I, as mentioned below, are talking. Here is my current >> draft. Please keep in mind that it's really just a set of notes trying to >> capture all the issues involved in creating a secure token format so it's a >> bit dense. My hope is that once all the issues are captured it can be >> completely re-written to be in something that looks more like English and is >> easier for actual implementers to follow. But for now I think it gives a >> good sense of the some of the security challenges in creating a secure token >> format. >> >> Yaron >> >> >> >> *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf >> Of *Nat Sakimura >> *Sent:* Tuesday, August 24, 2010 6:50 AM >> *To:* oauth >> *Subject:* [OAUTH-WG] OAuth Signature Draft Pre 00 >> >> >> >> Hi. >> >> >> >> It has been a few weeks since then I volunteered to do this work. >> >> I have written up to this pre 00 draft then have been doing some reality >> checks on some script languages etc. >> >> >> >> No. This pre-00 draft is far from being feature complete. >> >> I still need to copy and paste the Magic Signatures text etc. >> >> Also, I should add how this spec is being used in some of the major >> flows. >> >> >> >> However, since I will not be able to work on it this week, I thought it >> would be worthwhile to share this early draft so that you have some clarity >> into the progress. >> >> >> >> Apparently, Yaron has been working on it as well. We will compare the >> notes and try to merge, I hope. >> >> >> >> So, here it is! >> >> >> >> #For those of you who have seen the private draft, it has not been changed >> since July 31. >> >> >> >> Best, >> >> >> >> =nat >> >> >> >> >> >> ___ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Signature Draft Pre 00
The goal is to have a single unified draft. From: David Recordon [mailto:record...@gmail.com] Sent: Monday, September 27, 2010 7:00 AM To: Nat Sakimura; Yaron Goland Cc: oauth Subject: Re: [OAUTH-WG] OAuth Signature Draft Pre 00 I'm a bit confused between the relationship of Nat's I-D and the documents you and Mike recently posted. Is the goal to have one I-D? Nat's seems to have fewer options and different modes which makes it easier to read and understand. On Mon, Aug 30, 2010 at 11:47 AM, Yaron Goland mailto:yar...@microsoft.com>> wrote: BTW, Nat and I, as mentioned below, are talking. Here is my current draft. Please keep in mind that it's really just a set of notes trying to capture all the issues involved in creating a secure token format so it's a bit dense. My hope is that once all the issues are captured it can be completely re-written to be in something that looks more like English and is easier for actual implementers to follow. But for now I think it gives a good sense of the some of the security challenges in creating a secure token format. Yaron From: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org> [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On Behalf Of Nat Sakimura Sent: Tuesday, August 24, 2010 6:50 AM To: oauth Subject: [OAUTH-WG] OAuth Signature Draft Pre 00 Hi. It has been a few weeks since then I volunteered to do this work. I have written up to this pre 00 draft then have been doing some reality checks on some script languages etc. No. This pre-00 draft is far from being feature complete. I still need to copy and paste the Magic Signatures text etc. Also, I should add how this spec is being used in some of the major flows. However, since I will not be able to work on it this week, I thought it would be worthwhile to share this early draft so that you have some clarity into the progress. Apparently, Yaron has been working on it as well. We will compare the notes and try to merge, I hope. So, here it is! #For those of you who have seen the private draft, it has not been changed since July 31. Best, =nat ___ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Signature Draft Pre 00
I'm a bit confused between the relationship of Nat's I-D and the documents you and Mike recently posted. Is the goal to have one I-D? Nat's seems to have fewer options and different modes which makes it easier to read and understand. On Mon, Aug 30, 2010 at 11:47 AM, Yaron Goland wrote: > BTW, Nat and I, as mentioned below, are talking. Here is my current > draft. Please keep in mind that it's really just a set of notes trying to > capture all the issues involved in creating a secure token format so it's a > bit dense. My hope is that once all the issues are captured it can be > completely re-written to be in something that looks more like English and is > easier for actual implementers to follow. But for now I think it gives a > good sense of the some of the security challenges in creating a secure token > format. > > Yaron > > > > *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf > Of *Nat Sakimura > *Sent:* Tuesday, August 24, 2010 6:50 AM > *To:* oauth > *Subject:* [OAUTH-WG] OAuth Signature Draft Pre 00 > > > > Hi. > > > > It has been a few weeks since then I volunteered to do this work. > > I have written up to this pre 00 draft then have been doing some reality > checks on some script languages etc. > > > > No. This pre-00 draft is far from being feature complete. > > I still need to copy and paste the Magic Signatures text etc. > > Also, I should add how this spec is being used in some of the major flows. > > > > However, since I will not be able to work on it this week, I thought it > would be worthwhile to share this early draft so that you have some clarity > into the progress. > > > > Apparently, Yaron has been working on it as well. We will compare the notes > and try to merge, I hope. > > > > So, here it is! > > > > #For those of you who have seen the private draft, it has not been changed > since July 31. > > > > Best, > > > > =nat > > > > > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Signature Draft Pre 00
Sorry, I was wrong. "If Claim segment " is right. 2010/9/22 hdknr hidelafoglia : > Hi, > > If Crypto segment has a switch parameters of encryption or signature, > JSON Token seems to handle encrypted token as well as signed token. > > --- > hdknr > > > 2010/8/31 Yaron Goland : >> BTW, Nat and I, as mentioned below, are talking. Here is my current draft. >> Please keep in mind that it's really just a set of notes trying to capture >> all the issues involved in creating a secure token format so it's a bit >> dense. My hope is that once all the issues are captured it can be completely >> re-written to be in something that looks more like English and is easier for >> actual implementers to follow. But for now I think it gives a good sense of >> the some of the security challenges in creating a secure token format. >> >> Yaron >> >> >> >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of >> Nat Sakimura >> Sent: Tuesday, August 24, 2010 6:50 AM >> To: oauth >> Subject: [OAUTH-WG] OAuth Signature Draft Pre 00 >> >> >> >> Hi. >> >> >> >> It has been a few weeks since then I volunteered to do this work. >> >> I have written up to this pre 00 draft then have been doing some reality >> checks on some script languages etc. >> >> >> >> No. This pre-00 draft is far from being feature complete. >> >> I still need to copy and paste the Magic Signatures text etc. >> >> Also, I should add how this spec is being used in some of the major flows. >> >> >> >> However, since I will not be able to work on it this week, I thought it >> would be worthwhile to share this early draft so that you have some clarity >> into the progress. >> >> >> >> Apparently, Yaron has been working on it as well. We will compare the notes >> and try to merge, I hope. >> >> >> >> So, here it is! >> >> >> >> #For those of you who have seen the private draft, it has not been changed >> since July 31. >> >> >> >> Best, >> >> >> >> =nat >> >> >> >> >> >> ___ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Signature Draft Pre 00
Might actually want both @ same time, so might be better to expand -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of hdknr hidelafoglia Sent: Tuesday, September 21, 2010 12:39 PM To: Yaron Goland Cc: oauth Subject: Re: [OAUTH-WG] OAuth Signature Draft Pre 00 Hi, If Crypto segment has a switch parameters of encryption or signature, JSON Token seems to handle encrypted token as well as signed token. --- hdknr 2010/8/31 Yaron Goland : > BTW, Nat and I, as mentioned below, are talking. Here is my current draft. > Please keep in mind that it's really just a set of notes trying to > capture all the issues involved in creating a secure token format so > it's a bit dense. My hope is that once all the issues are captured it > can be completely re-written to be in something that looks more like > English and is easier for actual implementers to follow. But for now I > think it gives a good sense of the some of the security challenges in > creating a secure token format. > > Yaron > > > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Nat Sakimura > Sent: Tuesday, August 24, 2010 6:50 AM > To: oauth > Subject: [OAUTH-WG] OAuth Signature Draft Pre 00 > > > > Hi. > > > > It has been a few weeks since then I volunteered to do this work. > > I have written up to this pre 00 draft then have been doing some > reality checks on some script languages etc. > > > > No. This pre-00 draft is far from being feature complete. > > I still need to copy and paste the Magic Signatures text etc. > > Also, I should add how this spec is being used in some of the major flows. > > > > However, since I will not be able to work on it this week, I thought > it would be worthwhile to share this early draft so that you have some > clarity into the progress. > > > > Apparently, Yaron has been working on it as well. We will compare the > notes and try to merge, I hope. > > > > So, here it is! > > > > #For those of you who have seen the private draft, it has not been > changed since July 31. > > > > Best, > > > > =nat > > > > > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Signature Draft Pre 00
Hi, If Crypto segment has a switch parameters of encryption or signature, JSON Token seems to handle encrypted token as well as signed token. --- hdknr 2010/8/31 Yaron Goland : > BTW, Nat and I, as mentioned below, are talking. Here is my current draft. > Please keep in mind that it's really just a set of notes trying to capture > all the issues involved in creating a secure token format so it's a bit > dense. My hope is that once all the issues are captured it can be completely > re-written to be in something that looks more like English and is easier for > actual implementers to follow. But for now I think it gives a good sense of > the some of the security challenges in creating a secure token format. > > Yaron > > > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > Nat Sakimura > Sent: Tuesday, August 24, 2010 6:50 AM > To: oauth > Subject: [OAUTH-WG] OAuth Signature Draft Pre 00 > > > > Hi. > > > > It has been a few weeks since then I volunteered to do this work. > > I have written up to this pre 00 draft then have been doing some reality > checks on some script languages etc. > > > > No. This pre-00 draft is far from being feature complete. > > I still need to copy and paste the Magic Signatures text etc. > > Also, I should add how this spec is being used in some of the major flows. > > > > However, since I will not be able to work on it this week, I thought it > would be worthwhile to share this early draft so that you have some clarity > into the progress. > > > > Apparently, Yaron has been working on it as well. We will compare the notes > and try to merge, I hope. > > > > So, here it is! > > > > #For those of you who have seen the private draft, it has not been changed > since July 31. > > > > Best, > > > > =nat > > > > > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] OAuth Signature Draft Pre 00
Hi. It has been a few weeks since then I volunteered to do this work. I have written up to this pre 00 draft then have been doing some reality checks on some script languages etc. No. This pre-00 draft is far from being feature complete. I still need to copy and paste the Magic Signatures text etc. Also, I should add how this spec is being used in some of the major flows. However, since I will not be able to work on it this week, I thought it would be worthwhile to share this early draft so that you have some clarity into the progress. Apparently, Yaron has been working on it as well. We will compare the notes and try to merge, I hope. So, here it is! #For those of you who have seen the private draft, it has not been changed since July 31. Best, =nat Title: OAuth Signatures 1.0 draft 00 TOC Open Authentication Working GroupD. Balfanz Internet-DraftGoogle Intended status: InformationalJ. Bradley Expires: February 1, 2011Wingaa N. Sakimura (Editor) Nomura Research Institute L. Shephard P. Tarjan Facebook July 31, 2010 OAuth Signatures 1.0 draft 00draft-sakimura-oauth-signatures-00 Abstract This specification defines signing mechanism to be used in OAuth 2.0. The OAuth requests and responses together with signature related parameters are encoded into JSON envelope and then signing algorithm is applied to obtain Base64url encoded signature using signatory's key. The resulting signature is concatenated with the Base64url encoded JSON envelope to which the signature is applied by a period "." so that it could be included in URLs. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.” This Internet-Draft will expire on February 1, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Definitions 2. Envelope Structures 3. Creating Signature 4. Signature Verification 5. Key Discovery and the Trust 5.1. Shared key in HMAC-SHA256 5.2. X.509 Certificates 6. IANA Considerations 7. Security Considerations 8. Acknowledgements 9. References 9.1. Normative References 9.2. Informative References Appendix A. An Appendix § Authors' Addresses TOC 1. Definitions Server Descriptors A server descriptor is a https or http URL. This URL resolves to a document that describes the server (such as keys used to sign requests or tokens, location of certain endpoints, etc.). Signature A digital signature that provably binds a message to a signer's keypair or Hash-based Message Authentication Code that can be used to verify both the data integrity and the authenticity of a message. Signer In this specification, an arbitrary identifier associated with a key used in a signature. Base64url Encoding The URL and Filename safe variant of the base64 encoding as described in RFC4648 (Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” October 2006.) [RFC4648], section 5. HMAC-SHA256 Hash-based Message Authentication Code using SHA-256 as the hash function. RSA-SHA256 RSASSA-PKCS1-v1_5 signature algorithm from RFC3447 (Jonsson, J. and B. Kaliski, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1,” February 2003.) [RFC3447] section 8.2, also known as PKCS#1, using SHA-256 as the hash function for EMSA-PKCS1-v1_5. TOC 2. Envelope Structures OAuth Signature Envelope is a JSON object that contains
