[OAUTH-WG] Bls: OAuth Digest, Vol 73, Issue 56

[Panca Agus Ananda <[e-mail]>]

Dikirim dari ponsel cerdas BlackBerry 10 saya dengan jaringan Telkomsel.
Dari: [e-mail]
Terkirim: Sabtu, 22 November 2014 03.01
Ke: [e-mail]
Balas Ke: [e-mail]
Perihal: OAuth Digest, Vol 73, Issue 56


Send OAuth mailing list submissions to
        [e-mail]

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.ietf.org/mailman/listinfo/oauth
or, via email, send a message with subject or body 'help' to
        [e-mail]

You can reach the person managing the list at
        [e-mail]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."


Today's Topics:

   1. Re: Review of dynamic registration draft (Richer, Justin P.)
   2. Re: Review of dynamic registration draft (Richer, Justin P.)


----------------------------------------------------------------------

Message: 1
Date: Thu, 20 Nov 2014 20:34:37 +0000
From: "Richer, Justin P." <[e-mail]>
To: Kathleen Moriarty <[e-mail]>
Cc: oauth <[e-mail]>
Subject: Re: [OAUTH-WG] Review of dynamic registration draft
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"

Kathleen, thanks for your review. Responses inline.

On Nov 19, 2014, at 9:56 PM, Kathleen Moriarty <[e-mail]<mailto:[e-mail]>> wrote:

Hi,

I reviewed draft-Ietf-oauth-dyn-reg-20 and have the following questions before we move this to IETF last call.

Sect 2, Has there been any consideration in the WG of using alternate auth methods from HTTPAuth like HOBA?  I realize this is referencing Oauth defined methods from the framework draft, but would like to know what was considered or not.  HOBA is heading to IETF last call soon.

Nobody brought up HOBA in this working group. This field is intentionally extensible, so if there's interest in defining how to use HOBA for OAuth client authentication it will make a perfectly reasonable extension document.


Section 6:  why is there a choice on TLS?  I'd recommend you make it require 1.2 unless there is a really compelling argument to have that must as either 1.2 or 1.0

We copied this text straight from RFC6749. I know that a similar section exists in JWS with updated language, and we could adopt that directly here:


   Which TLS version(s) ought to be implemented will
   vary over time, and depend on the widespread deployment and known
   security vulnerabilities at the time of implementation.  At the time
   of this writing, TLS version 1.2 [RFC5246<https://tools.ietf.org/html/rfc5246>] is the most recent
   version.

   To protect against information disclosure and tampering,
   confidentiality protection MUST be applied using TLS with a
   ciphersuite that provides confidentiality and integrity protection.
   See current publications by the IETF TLS working group, including RFC<https://tools.ietf.org/html/rfc6176>
   6176<https://tools.ietf.org/html/rfc6176> [RFC6176<https://tools.ietf.org/html/rfc6176>] for guidance on the ciphersuites currently considered
   to be appropriate for use.  Also, see Recommendations for Secure Use
   of TLS and DTLS [I-D.ietf-uta-tls-bcp<https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-37#ref-I-D.ietf-uta-tls-bcp>] for recommendations on
   improving the security of software and services using TLS.

   Whenever TLS is used, the identity of the service provider encoded in
   the TLS server certificate MUST be verified using the procedures
   described in Section 6 of RFC 6125<https://tools.ietf.org/html/rfc6125#section-6> [RFC6125<https://tools.ietf.org/html/rfc6125>]

Will that work?

Sect 6 paragraph 5
Why are the security recommendations listed as 'could'?

Things listed as 'could' in this section were seen to be non-normative recommendations of possible mitigating behaviors. In other words, not trying to be prescriptive with the actions here but providing guidance. Most of these were relaxed from normative requirements in earlier drafts from WG feedback


Sect 6 paragraph 7
What makes it 'valid and trusted'?  The flow of this paragraph could be improved so the terms valid and trusted are connected to earlier statements to separate it better from the plain JSON objects.

On the first level, this includes validating the JWS on the statement itself, but as is usually the case, determining "trust" of a source is going to be very application specific. I'm not quite


Please add a section or interspersed statements on privacy considerations.  Include text on what may be of concern (names, contacts, etc.) and what can be done to protect the values (interspersed may be easier) or that they may be left out to remove concerns.

Most of this protocol doesn't deal with any user information, and so I don't think there are any privacy considerations for most of the document. The one part of this protocol that I can see being a possible privacy consideration is the "contacts" meatadata field, which contains user contact information. Since this field is self-asserted by the client or developer (whoever's doing the registration) for the express purpose of providing a means of contacting the developer of the client, I'm not sure what concerns this might have, if any.

Do you have any other specific parts that you think would have privacy concerns that you'd like to address?

Thanks for the review and the thoughtful comments.

 -- Justin



Thank you,
Kathleen

Sent from my iPhone
_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/oauth/attachments/20141120/55188a87/attachment.html>

------------------------------

Message: 2
Date: Thu, 20 Nov 2014 20:47:08 +0000
From: "Richer, Justin P." <[e-mail]>
To: Kathleen Moriarty <[e-mail]>
Cc: oauth <[e-mail]>
Subject: Re: [OAUTH-WG] Review of dynamic registration draft
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"

Sorry, a sentence trailed off -- I meant to say:


Sect 6 paragraph 7
What makes it 'valid and trusted'?  The flow of this paragraph could be improved so the terms valid and trusted are connected to earlier statements to separate it better from the plain JSON objects.

On the first level, this includes validating the JWS on the statement itself, but as is usually the case, determining "trust" of a source is going to be very application specific. I'm not quite

... convinced that we can really do much more than that, though we can explicitly state that this is the case if that would help. I agree that "valid and trusted" is a bit vague.

-- Justin



On Nov 20, 2014, at 3:34 PM, Justin Richer <[e-mail]<mailto:[e-mail]>> wrote:

Kathleen, thanks for your review. Responses inline.

On Nov 19, 2014, at 9:56 PM, Kathleen Moriarty <[e-mail]<mailto:[e-mail]>> wrote:

Hi,

I reviewed draft-Ietf-oauth-dyn-reg-20 and have the following questions before we move this to IETF last call.

Sect 2, Has there been any consideration in the WG of using alternate auth methods from HTTPAuth like HOBA?  I realize this is referencing Oauth defined methods from the framework draft, but would like to know what was considered or not.  HOBA is heading to IETF last call soon.

Nobody brought up HOBA in this working group. This field is intentionally extensible, so if there's interest in defining how to use HOBA for OAuth client authentication it will make a perfectly reasonable extension document.


Section 6:  why is there a choice on TLS?  I'd recommend you make it require 1.2 unless there is a really compelling argument to have that must as either 1.2 or 1.0

We copied this text straight from RFC6749. I know that a similar section exists in JWS with updated language, and we could adopt that directly here:


   Which TLS version(s) ought to be implemented will
   vary over time, and depend on the widespread deployment and known
   security vulnerabilities at the time of implementation.  At the time
   of this writing, TLS version 1.2 [RFC5246<https://tools.ietf.org/html/rfc5246>] is the most recent
   version.

   To protect against information disclosure and tampering,
   confidentiality protection MUST be applied using TLS with a
   ciphersuite that provides confidentiality and integrity protection.
   See current publications by the IETF TLS working group, including RFC<https://tools.ietf.org/html/rfc6176>
   6176<https://tools.ietf.org/html/rfc6176> [RFC6176<https://tools.ietf.org/html/rfc6176>] for guidance on the ciphersuites currently considered
   to be appropriate for use.  Also, see Recommendations for Secure Use
   of TLS and DTLS [I-D.ietf-uta-tls-bcp<https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-37#ref-I-D.ietf-uta-tls-bcp>] for recommendations on
   improving the security of software and services using TLS.

   Whenever TLS is used, the identity of the service provider encoded in
   the TLS server certificate MUST be verified using the procedures
   described in Section 6 of RFC 6125<https://tools.ietf.org/html/rfc6125#section-6> [RFC6125<https://tools.ietf.org/html/rfc6125>]

Will that work?

Sect 6 paragraph 5
Why are the security recommendations listed as 'could'?

Things listed as 'could' in this section were seen to be non-normative recommendations of possible mitigating behaviors. In other words, not trying to be prescriptive with the actions here but providing guidance. Most of these were relaxed from normative requirements in earlier drafts from WG feedback


Sect 6 paragraph 7
What makes it 'valid and trusted'?  The flow of this paragraph could be improved so the terms valid and trusted are connected to earlier statements to separate it better from the plain JSON objects.

On the first level, this includes validating the JWS on the statement itself, but as is usually the case, determining "trust" of a source is going to be very application specific. I'm not quite






Please add a section or interspersed statements on privacy considerations.  Include text on what may be of concern (names, contacts, etc.) and what can be done to protect the values (interspersed may be easier) or that they may be left out to remove concerns.

Most of this protocol doesn't deal with any user information, and so I don't think there are any privacy considerations for most of the document. The one part of this protocol that I can see being a possible privacy consideration is the "contacts" meatadata field, which contains user contact information. Since this field is self-asserted by the client or developer (whoever's doing the registration) for the express purpose of providing a means of contacting the developer of the client, I'm not sure what concerns this might have, if any.

Do you have any other specific parts that you think would have privacy concerns that you'd like to address?

Thanks for the review and the thoughtful comments.

 -- Justin



Thank you,
Kathleen

Sent from my iPhone
_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/oauth/attachments/20141120/94065061/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
OAuth mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth


------------------------------

End of OAuth Digest, Vol 73, Issue 56
*************************************