Subject: Re: [OAUTH-WG] Review Comments for draft-ietf-oauth-proof-of-possession-02

From: Mike Jones <[email-masked]>
Date: Tue, 11 Aug 2015 05:12:48 +0000

Replies inline…

From: OAuth [mailto:[email-masked]] On Behalf Of Nat Sakimura
Sent: Wednesday, March 25, 2015 6:38 AM
To: oauth
Subject: [OAUTH-WG] Review Comments for draft-ietf-oauth-proof-of-possession-02

Dear OAuthers:

Here is my belated review comments on draft-ietf-oauth-proof-of-possession-02

Below, [POPA] stands for https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01

Abstract
============
It is probably better to spell out that this document is describing the JWT format that can be used for sender constraint (5.2 of [POPA]) and key confirmation (5.3 of [POPA]). This will make it easier for the reader to understand what this document aims at.

It does not seem to me that the “Sender Constraint” concept described in 5.3 of [POPA] is the same thing as identifying a proof-of-possession key within a JWT, which is the purpose of this specification.  In this specification, the issuer makes a statement that the presenter can confirm possession of a key.  I don’t know how that would map into a “Sender Constraint”.  For one thing, which party are you considering to be the “Sender”?  Accordingly, I left the abstract unchanged.

Accordingly, we should consider the title change to something like:
JWT Sender Confirmation Token Syntax
  OR
borrowing from the financial concept which I believe is the origin of the concept of "bearer token",
JWT Registered Token Syntax
-- here, "Registered" mean that either the sender constraint or key confirmation is registered within or in conjunction with the token.

I changed the title in -03 to “Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)” to make it clear this draft is about PoP key semantics for JWTs – not the proof-of-possession mechanism itself.  I’ve already responded to the “Sender Constraint” suggestion above.  Per my earlier response, I don’t believe that “Registered Token” is standard terminology, and so would confuse more than it would clarify.

1. Introduction
==============
Consider referencing draft-ietf-oauth-pop-architecture.
It will be clearer for the reader then, and the text will be shorter.

Again, I suspect you’re asking me to reference this draft for the “Sender Constraint” terminology, which is both vaguely defined in [POPA], and doesn’t match what this specification does.  Therefore, I did not do this here, although other appropriate references to [POPA] are included.

2. Terminology - Presenter
========================
Sentence 1
-------------------
Not sure if the first sentence is accurately reflecting the intent.
It excludes rogue party presenting the token (and fails) from presenter.
If so, it is fine but using more qualified term like "authorized presenter" may make it easier
for the reader to parse.

Otherwise revise the definition.

I believe the “Presenter” definition accurately matches its usage in this specification.  While this is related to a different discussion, I’m not aware of a definition for “Authorized Presenter” that could be referenced that would add further clarity beyond the existing definition.  (Note that the OpenID Connect “azp” claim is for an “Authorized Party” to which the token was issued – not an “Authorized Presenter”.  Also, note that the usage of “azp” in http://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-04 is inconsistent with its definition in OpenID Connect, and so should probably be revised to use the “Authorized Party” terminology or removed, as it does not identify an “Authorized Presenter” in the way that I think you are using the term.)

Sentence 2
-------------------
"issuer or a party different from the issuer" is not constraining anything and meaningless.
There are more easier to parse and accurate text coming in the main text, too.
Drop.

The phrase expresses the intentional *lack of constraint*, by stating that the presenter might be the issuer or might be a party different from the issuer.  Too many times in the past people thought the two were the same party (and indeed, this error occurred in several places in -02), therefore, I believe that expressing this non-constraint adds value.  If you want to suggest alternative wording to express this non-constraint, I’d be glad to consider it.

3. Proof-Of-Posession Representation
==============================
Title
---------
Perhaps "Sender Representation in JWT" is more reflective of the content.

This was changed to “Representations for Proof-of-Possession Keys” in -03 to clarifying that it is the PoP key being represented, not the proof-of-possession itself.

Para 2
-------------
The paragraph describes two ways of sender confirmation:
(1) Sender Constraint
(2) Key Confirmation
It should refer to 5.2 and 5.3 of [POPA] for it, as well as align the terminology.

As described above, the “Sender Constraint” terminology in [POPA] does not match what this specification does.

Then, it goes on to describe (1) very briefly, in which it is just spelling out "iss" and "sub".

I understand the use of sub in this section comes down from SAML but I feel that some separation between sub and presenter would be nice.

For example, when I am presenting the token using an app that I installed on my iPhone, the presenter is that app and not me, while the sub still may be me. The app is the authorized presenter/party (azp) of the token. The JWT may well be about the sub but presented by some software component that should be independently identified.

So my proposal is to create a new subsection on (1) for the completeness, which is going to be a new 3.1, and to use a claim like "azp" instead of "sub" to identify the presenter. Less overload would cause less confusion later, IMHO.

Per your request, https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-03#section-3 was revised to include a description of the use of the “azp” claim as a choice that applications can employ to identify the presenter, if appropriate.

3.1
======
Title
--------
Perhaps "Confirmation Key Representation for an Asymmetric Key" is more reflective of the content.

This was changed to “Representation for an Asymmetric Proof-of-Possession Key”.

3.2
========
Title
-----------
Perhaps "Confirmation Key Representation for a Symmetric Key" is more reflective of the content.

This was changed to “Representation for an Encrypted Symmetric Proof-of-Possession Key”.

Last Para
-----------------
I feel a bit like needing to sniff into the content of jwk to find out what type may not be optimal, though I do not have a concrete proposal a this time.

The “jwe” member was introduced in -03 to eliminate the need for this sniffing.

3.3
======
Title
---------
Perhaps "Confirmation Key Representation by Key ID" is more reflective of the content.

This was changed to “Representation of a Key ID for a Proof-of-Possession Key”.

Para 1
-----------
There has been some discussion of using thumbprint instead of a blob "kid".
This is a valid option. If we are to overload the "kid" member for this purpose, we need to find a way to signal that it is a thumbprint.
It may very well be better to define a separate member name then for the thumbprint. The title then changes to "-- by Key ID" to "-- by reference".

For the same reasons that the “jkt” definition was removed from draft-ietf-jose-jwk-thumbprint, it’s not clear that it’s needed here.  Applications are free to define that the “kid” is to contain a key thumbprint using a particular hash function.

Also, it is conceivable to use the combination of "kid" and "jku". This aspect is not spelled out here but appears that some magic happens for the key distribution.

You’re right that if “kid” is used, unless the key is also transmitted in the “cnf” claim, distribution of the key is out of scope of the specification.  I can imagine methods using “jku” but it seems like we should discuss this more before normatively specifying it at this time.

3.4
========
Since "cnf" appears before 3.4, it may be better to bring 3.4 at the front.

Agreed.  Sorry I missed doing this in -03.  I’ll plan to do this in -04.

5.2.2
=========
Add "azp" and "jkt".

o  Confirmation Method Value: "azp"
o  Confirmation Method Description: Client ID of the Authorized Presenter
o  Change Controller: IESG
o  Specification Document(s): Section [TBD] of [[ this document ]]

Having a Client ID doesn’t identify a proof-of-possession key, so this request seems to be out of place relative to the purpose of this specification.

o  Confirmation Method Value: "jkt"
o  Confirmation Method Description: JWK Thumbprint of the Confirmation Key
o  Change Controller: IESG
o  Specification Document(s): Section [TBD] of [[ this document ]]

As discussed earlier, “kid” can already be used to hold a key thumbprint value.

o  Confirmation Method Value: "jku"
o  Confirmation Method Description: JWK URI of the Confirmation Key
o  Change Controller: IESG
o  Specification Document(s): Section [TBD] of [[ this document ]]

We should have a discussion focused specifically on this proposed addition.  I can see the value of it, but would like to get input from more working group members.  What do people think?  (If this discussion doesn’t happen based on this response, we should probably start a separate thread on this topic.)

Privacy Consideration
========================
It is missing privacy consideration. It is not required per se, but since Key Confirmation method with ephemeral key can be less privacy intrusive compared to other sender confirmation method so adding some text around it may be a good idea.

Can you supply some specific proposed text for -04?

Best,
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

Thanks again for your useful review comments!

                                                            -- Mike

---

From: Mike Jones <[email-masked]>
Date: Tue, 11 Aug 2015 05:24:23 +0000

I believe that I’ve now responded line-by-line to all the WGLC comments received.  If I missed any from any of you, please let me know.

After discussion of my responses this week, unless disagreements arise, I’ll plan to publish -04 next week to incorporate the remaining resolutions that have been discussed and planned for the next draft, such as allowing symmetric keys in encrypted JWTs to be represented as simple JWKs in the “jwk” claim.

                                                            Best wishes,
                                                            -- Mike

From: Mike Jones
Sent: Thursday, July 30, 2015 7:49 PM
To: 'Nat Sakimura'; oauth
Subject: RE: [OAUTH-WG] Review Comments for draft-ietf-oauth-proof-of-possession-02

I typically do respond to review comments line-by-line but ran out of time to do this before Prague.  (I was doing things like working with Brian on the Token Exchange deck, preparing my remarks to the COSE WG, etc.)  I’ll plan to do this sometime early next week, which is the soonest I’ll be able to get to it, given other things currently on my plate.

FYI, I did read through all of your and other’s comments and applied most of them – for instance, off the top of my head, clarifying how “azp” could be used in identifying the presenter, eliminating the need to sniff the “jwk” value, and updating the title to be more evocative of what the specification actually achieves.

                                                            Cheers,
                                                            -- Mike

From: OAuth [mailto:[email-masked]] On Behalf Of Nat Sakimura
Sent: Thursday, July 30, 2015 6:36 PM
To: oauth
Subject: Re: [OAUTH-WG] Review Comments for draft-ietf-oauth-proof-of-possession-02

I cannot find any disposition of comment (DoC) to this review that the WG Chairs asked.
Nor I see much of them reflected in -03.

The process I would imagine to be the editors to

1) Provide the DoC [accept, discuss, reject (with reasons)],
2) Open up series of discussions on discuss items and drive towards the (rough) consensus.

Since the diff between -02 and -03 is small, much of the above comments still applies.

Looking forward to see the DoC.

Nat

2015-03-25 22:37 GMT+09:00 Nat Sakimura <[email-masked]<mailto:[email-masked]>>:
Dear OAuthers:

Below, [POPA] stands for https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-pop-architecture-01&data=01%7c01%7cMichael.Jones%40microsoft.com%7c8e3a1c80800044afea6408d299487914%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=aAlUfVrPuS6gZpFdW89pHCw2DWrRcftagluPdgF3XzQ%3d>

Abstract
============

1. Introduction
==============

Sentence 2
-------------------

Para 2
-------------

3.1
======
Title
--------

3.2
========
Title
-----------

Last Para
-----------------

3.3
======
Title
---------

Para 1
-----------

3.4
========

5.2.2
=========
Add "azp" and "jkt".

Privacy Consideration
========================

Best,
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fnat.sakimura.org%2f&data=01%7c01%7cMichael.Jones%40microsoft.com%7c8e3a1c80800044afea6408d299487914%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=AkE994JMtcV9SGK3yaZ9beCp4r4RIMn9Fs%2bZU9ESdeM%3d>
@_nat_en

--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fnat.sakimura.org%2f&data=01%7c01%7cMichael.Jones%40microsoft.com%7c8e3a1c80800044afea6408d299487914%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=AkE994JMtcV9SGK3yaZ9beCp4r4RIMn9Fs%2bZU9ESdeM%3d>
@_nat_en

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 19 Aug 2015 12:29:02 +0900

Thanks. I am working on your response now.

2015-08-11 14:24 GMT+09:00 Mike Jones <[email-masked]>:

> I believe that I’ve now responded line-by-line to all the WGLC comments
> received.  If I missed any from any of you, please let me know.
>
>
>
> After discussion of my responses this week, unless disagreements arise,
> I’ll plan to publish -04 next week to incorporate the remaining resolutions
> that have been discussed and planned for the next draft, such as allowing
> symmetric keys in encrypted JWTs to be represented as simple JWKs in the
> “jwk” claim.
>
>
>
>                                                             Best wishes,
>
>                                                             -- Mike
>
>
>
> *From:* Mike Jones
> *Sent:* Thursday, July 30, 2015 7:49 PM
> *To:* 'Nat Sakimura'; oauth
> *Subject:* RE: [OAUTH-WG] Review Comments for
> draft-ietf-oauth-proof-of-possession-02
>
>
>
> I typically do respond to review comments line-by-line but ran out of time
> to do this before Prague.  (I was doing things like working with Brian on
> the Token Exchange deck, preparing my remarks to the COSE WG, etc.)  I’ll
> plan to do this sometime early next week, which is the soonest I’ll be able
> to get to it, given other things currently on my plate.
>
>
>
> FYI, I did read through all of your and other’s comments and applied most
> of them – for instance, off the top of my head, clarifying how “azp” could
> be used in identifying the presenter, eliminating the need to sniff the
> “jwk” value, and updating the title to be more evocative of what the
> specification actually achieves.
>
>
>
>                                                             Cheers,
>
>                                                             -- Mike
>
>
>
> *From:* OAuth [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Nat Sakimura
> *Sent:* Thursday, July 30, 2015 6:36 PM
> *To:* oauth
> *Subject:* Re: [OAUTH-WG] Review Comments for
> draft-ietf-oauth-proof-of-possession-02
>
>
>
> 2015-03-25 22:37 GMT+09:00 Nat Sakimura <[email-masked]>:
>
> Dear OAuthers:
>
>
>
> Below, [POPA] stands for
> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-pop-architecture-01&data=01%7c01%7cMichael.Jones%40microsoft.com%7c8e3a1c80800044afea6408d299487914%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=aAlUfVrPuS6gZpFdW89pHCw2DWrRcftagluPdgF3XzQ%3d>
>
>
>
> Abstract
>
> ============
>
> It is probably better to spell out that this document is describing the
> JWT format that can be used for sender constraint (5.2 of [POPA]) and key
> confirmation (5.3 of [POPA]). This will make it easier for the reader to
> understand what this document aims at.
>
>
>
> -- here, "Registered" mean that either the sender constraint or key
> confirmation is registered within or in conjunction with the token.
>
>
>
> 1. Introduction
>
> ==============
>
> I understand the use of sub in this section comes down from SAML but I
> feel that some separation between sub and presenter would be nice.
>
> For example, when I am presenting the token using an app that I installed
> on my iPhone, the presenter is that app and not me, while the sub still may
> be me. The app is the authorized presenter/party (azp) of the token. The
> JWT may well be about the sub but presented by some software component that
> should be independently identified.
>
>
> So my proposal is to create a new subsection on (1) for the completeness,
> which is going to be a new 3.1, and to use a claim like "azp" instead of
> "sub" to identify the presenter. Less overload would cause less confusion
> later, IMHO.
>
>
>
> 3.1
>
> ======
>
> Title
>
> --------
>
> I feel a bit like needing to sniff into the content of jwk to find out
> what type may not be optimal, though I do not have a concrete proposal a
> this time.
>
>
>
> 3.3
>
> ======
>
> Title
>
> ---------
>
> This is a valid option. If we are to overload the "kid" member for this
> purpose, we need to find a way to signal that it is a thumbprint.
>
> It may very well be better to define a separate member name then for the
> thumbprint. The title then changes to "-- by Key ID" to "-- by reference".
>
>
>
> Also, it is conceivable to use the combination of "kid" and "jku". This
> aspect is not spelled out here but appears that some magic happens for the
> key distribution.
>
>
>
> 3.4
>
> ========
>
> It is missing privacy consideration. It is not required per se, but since
> Key Confirmation method with ephemeral key can be less privacy intrusive
> compared to other sender confirmation method so adding some text around it
> may be a good idea.
>
>
>
> Best,
>
> --
>
> Nat Sakimura (=nat)
>
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fnat.sakimura.org%2f&data=01%7c01%7cMichael.Jones%40microsoft.com%7c8e3a1c80800044afea6408d299487914%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=AkE994JMtcV9SGK3yaZ9beCp4r4RIMn9Fs%2bZU9ESdeM%3d>
> @_nat_en
>
>
>
>
>
> --
>
> Nat Sakimura (=nat)
>
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fnat.sakimura.org%2f&data=01%7c01%7cMichael.Jones%40microsoft.com%7c8e3a1c80800044afea6408d299487914%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=AkE994JMtcV9SGK3yaZ9beCp4r4RIMn9Fs%2bZU9ESdeM%3d>
> @_nat_en
>

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 19 Aug 2015 13:00:19 +0900

Inline:

2015-08-11 14:12 GMT+09:00 Mike Jones <[email-masked]>:

> Replies inline…
>
>
>
> *From:* OAuth [mailto:[email-masked]] *On Behalf Of *Nat Sakimura
> *Sent:* Wednesday, March 25, 2015 6:38 AM
> *To:* oauth
> *Subject:* [OAUTH-WG] Review Comments for
> It does not seem to me that the “Sender Constraint” concept described in
> 5.3 of [POPA] is the same
>

5.2 I guess, not 5.3.

> thing as identifying a proof-of-possession key within a JWT, which is the
> purpose of this specification.  In this specification, the issuer makes a
> statement that the presenter can confirm possession of a key.  I don’t know
> how that would map into a “Sender Constraint”.  For one thing, which party
> are you considering to be the “Sender”?  Accordingly, I left the abstract
> unchanged.
>

OK. Since the draft was titled "Proof of Possession Semantics for for JSON
Web Tokens (JWTs)", I pointed it out that it should not only talk about 5.3
of [POPA] but also 5.2. However, now that you have changed the tile to "Proof
of Possession *KEY* Semantics for for JSON Web Tokens (JWTs)", this issue
is resolved. It would be nice to state that it is talking about 5.3 of
[POPA] in the introduction though.

> I changed the title in -03 to “Proof-of-Possession Key Semantics for JSON
> Web Tokens (JWTs)” to make it clear this draft is about PoP key semantics
> for JWTs – not the proof-of-possession mechanism itself.  I’ve already
> responded to the “Sender Constraint” suggestion above.  Per my earlier
> response, I don’t believe that “Registered Token” is standard terminology,
> and so would confuse more than it would clarify.
>

Now that you have clarified that this document is only about 5.3 of [POPA],
the title in -03 is appropriate.

NOTE: "Registered *" is a very well established term in financial industry,
describing kind of "token" needed to be presented to exercise the right
assigned to it.
e.g., Registered Security, Registered Share Certificate, etc.

> Again, I suspect you’re asking me to reference this draft for the “Sender
> Constraint” terminology, which is both vaguely defined in [POPA], and
> doesn’t match what this specification does.  Therefore, I did not do this
> here, although other appropriate references to [POPA] are included.
>

It would be nice to point out that this document is talking about the model
presented in 5.3 of [POPA].
My suggestion: Insert ", *as described in section 5.3 of [POPA]"* before
the end of the Para 1.

   This specification defines how to express a declaration in a JSON Web
   Token (JWT) [JWT] that the presenter of the JWT possesses a
   particular key and that the recipient can cryptographically confirm
   proof-of-possession of the key by the presenter.  This property is
   also sometimes described as the presenter being a holder-of-key,
   *as described in section 5.3 of [POPA]. *

> I believe the “Presenter” definition accurately matches its usage in this
> specification.  While this is related to a different discussion, I’m not
> aware of a definition for “Authorized Presenter” that could be referenced
> that would add further clarity beyond the existing definition.  (Note that
> the OpenID Connect “azp” claim is for an “Authorized Party” to which the
> token was issued – not an “Authorized Presenter”.  Also, note that the
> usage of “azp” in
> http://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-04 is
> inconsistent with its definition in OpenID Connect, and so should probably
> be revised to use the “Authorized Party” terminology or removed, as it does
> not identify an “Authorized Presenter” in the way that I think you are
> using the term.)
>
>
>

It is not a good practice to define such a generic word like "presenter".
Since you have used "presenter" as party that holds the key,
we have lost the word for the rogue party that presents the token
without the key.

Also, the current definition includes the issuer in the presenter.
Issuer is not typically a party that is supposed to present the token to
the resource,
so the term seems to be especially weird.

> The phrase expresses the intentional **lack of constraint**, by stating
> that the presenter might be the issuer or might be a party different from
> the issuer.  Too many times in the past people thought the two were the
> same party (and indeed, this error occurred in several places in -02),
> therefore, I believe that expressing this non-constraint adds value.  If
> you want to suggest alternative wording to express this non-constraint, I’d
> be glad to consider it.
>

What is the most usual case? Is presenter usually the issuer?
I do not think so.
So, if we really want to express the lack of constraint, then something
like this would be better:

The presenter is usually distinct from the issuer, but the issuer can be a
presenter as well.

Also, I have to point out that the characteristics of this sentence is more
like a note to definition and not the definition itself.

> This was changed to “Representations for Proof-of-Possession Keys” in -03
> to clarifying that it is the PoP key being represented, not the
> proof-of-possession itself.
>

OK.

> Para 2

The title change clarified the situation so now it is ok.

> Per your request,
> https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-03#section-3
> was revised to include a description of the use of the “azp” claim as a
> choice that applications can employ to identify the presenter, if
> appropriate.
>

Thank you.

> This was changed to “Representation for an Asymmetric Proof-of-Possession

Thanks.

> Title

Thanks.

> Last Para

Thanks.

> This was changed to “Representation of a Key ID for a Proof-of-Possession

Thanks.

> For the same reasons that the “jkt” definition was removed from
> draft-ietf-jose-jwk-thumbprint, it’s not clear that it’s needed here.
> Applications are free to define that the “kid” is to contain a key
> thumbprint using a particular hash function.
>

OK. So you mean that it should be specified in the application layer. That
is acceptable, but then mentioning it in the text would be nice.

> You’re right that if “kid” is used, unless the key is also transmitted in
> the “cnf” claim, distribution of the key is out of scope of the
> specification.  I can imagine methods using “jku” but it seems like we
> should discuss this more before normatively specifying it at this time.
>

Looking forward to.

> Agreed.  Sorry I missed doing this in -03.  I’ll plan to do this in -04.

Looking forward to.
Note that this is not an endorsement for structured cnf, but rather,
it was just an editorial point that I raised.

> Having a Client ID doesn’t identify a proof-of-possession key, so this
> request seems to be out of place relative to the purpose of this
> specification.
>

Indeed. If the title was like before the change, it would have been, but
now the title and the scope is smaller, it is out of scope, I think..

> As discussed earlier, “kid” can already be used to hold a key thumbprint

OK.

> We should have a discussion focused specifically on this proposed
> addition.  I can see the value of it, but would like to get input from more
> working group members.  What do people think?  (If this discussion doesn’t
> happen based on this response, we should probably start a separate thread
> on this topic.)
>

OK.

> Privacy Consideration

When do you expect -04?
Depending on it, I may be able to.

---

From: Mike Jones <[email-masked]>
Date: Thu, 20 Aug 2015 00:41:00 +0000

Privacy Consideration
========================

When do you expect -04?

I expect to work on this on my Friday morning – 1.5 days from now.

                                                                Best wishes,
                                                                -- Mike

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 20 Aug 2015 22:39:38 +0900

Sorry, I'm completely sold out till then...
I could do it over the weekend.

2015年8月20日木曜日、Mike Jones<[email-masked]>さんは書きました:

>                                                                 Best
> wishes,