date:20170307

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-native-apps-08.txt

2017-03-07 Thread John Bradley

That is theory that CTAP should let web-views work.  

I just ran a test on the current shipping Android build. U2F is only working 
from the View controller and system browser.  
Web-view is not currently exposing CTAP.

I believe that is also the case on iOS, but haven't built a app to test it.

This first version of the BCP doesn’t go into advanced issues around Web 
Auth/Fido in detail.  We know that currently WebView/View controller/Token 
Agent work with existing CTAP implementations. 

Once we have systems deployed that can use CTAP from a web view we can update 
the BCP.

We may also have a definitional problem, we consider the Windows token broker 
in SSO mode to fit the model of a view controller/Web View in that it is 
sandboxed from the app , rather than considering it a web-view.   I know that 
the token broker can support WebAuthentication (CTAP 2) in recent RS2 builds of 
Win 10.  

John B.


> On Mar 7, 2017, at 5:16 AM, Anthony Nadalin  wrote:
> 
> Not true John, the CTAP support that is current would support the web-view 
> w/o any changes 
> 
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org ] 
> On Behalf Of John Bradley
> Sent: Monday, March 6, 2017 12:16 PM
> To: Hannes Tschofenig  >
> Cc: internet-dra...@ietf.org ; 
> oauth@ietf.org 
> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-native-apps-08.txt
> 
> On fido I can tell you that for security reasons U2F wont work from a 
> web-view currently.
> 
> Once we move to Web Auth (Fido 2) where the OS provides a API for apps to 
> call to get the token it will work but the tokens are audianced to the app 
> based on its developer key and bundle_id so that a app cant ask for a token 
> for a different site to do correlation. 
> 
> It is true that Fido UAF currently requires a web-view to work as the 
> authenticator is effectively compiled in to each application, and that 
> application has access to the private keys on most platforms (Samsung knox 
> being the only exception to that that I know of where the keys are managed by 
> a common API to hardware key storage, but they are scoped like U2F as well)
> 
> So for the most part it is true and that unless you use the browser to get 
> the Fido token the audience is for the app.
> Example  Salesforce creates native app that may use enterprise SSO via SAML, 
> and the enterprise may use Fido as a authentication factor.
> If they use the webview + fido API approach the app can only get a token for 
> SalesForce based on its signing key.  It could fire up the web-view and do 
> U2F authentication with the enterprise after Salesforec has redirected the 
> user.  However it will give every enterprise a token audience to Salesforce 
> with a salesforce specific key.   If there is a second app for say Slack if 
> they do the same thing the enterprise would get a slack audienced token and a 
> slack key forcing a separate registration. 
> 
> The recommended alternative is that the app use a custom tab for the user to 
> SalesForce and that redirect to the enterprise.
> The enterprise gets the same token/key with the correct audience from all 
> apps on the device using the browser or custom tab. 
> The user may not need to signin a second time, and if they do there Fido 
> token will not need to be re-registerd.
> 
> The Fido API approach really only works for first party apps like PayPal if 
> the the app is not doing federation and paypal is doing the authentication 
> for there own app.
> 
> Token binding private keys have similar issues.   The pool of private keys 
> will probably not be shared between apps, and not between the app and the 
> browser (Win 10 may be an exception but it is not documented yet)
> 
> In the case of using AppAuth with token binding the browser maintains the 
> keys so the enterprise would be able to see the same key and use the same 
> cookies across all AppAuth Apps.
> 
> You can include token binding in your app, however the token bindings and 
> cookies are going to be sand boxed per app.  
> Depending on implementation the app gets access to the cookie, but perhaps 
> not to the private token binding key.  (At least I don't think it will in 
> Android embedded webview).
> 
> We could expand on this later in an update to the BCP once Web Authentication 
> and Token Binding are final.
> 
> There are still some unknowns, but in general for any sort of SSO/Federation 
> 3rd party app I don’t see recommending anything other than a custom tab/ view 
> controller/ external browser.
> 
> William can take the formatting question:)
> 
> John B.
>> On Mar 6, 2017, at 4:41 PM, Hannes Tschofenig  
>> wrote:
>> 
>> Hi William, Hi John,
>> 
>> I just re-read version -8 of the document again.
>> 
>> Two minor remarks only.
>> 
>> Editorial issue: Why do you need to introduce a single sub-section 
>> within Section 7.1. (namely

Re: [OAUTH-WG] Shepherd writeup for OAuth 2.0 Authorization Server Metadata

2017-03-07 Thread Mike Jones

OpenID Connect implementations are not required to implement this functionality 
but most do, by virtue of implementing the OpenID Connect metadata specified in 
https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata.  
The OAuth AS Metadata spec is intentionally compatible with this specification.

If you want to include the compatible OpenID Connect examples, there are 34 ASs 
and 9 clients listed at http://openid.net/certification/ that implement 
metadata compatible with the AS metadata specification.  See the "Config OP" 
and "Config RP" columns.

The usage examples I provided in my previous reply were all OAuth examples that 
did not assume an implementation of OpenID Connect.

Best wishes,
-- Mike

-Original Message-
From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] 
Sent: Tuesday, March 7, 2017 11:07 AM
To: Mike Jones ; oauth@ietf.org; Phil Hunt 

Subject: Re: [OAUTH-WG] Shepherd writeup for OAuth 2.0 Authorization Server 
Metadata

Hi Mike

thanks for the quick response and for the wording suggestions.

Regarding the implementations are OpenID Connect implementations required to 
implement this functionality?

On 03/07/2017 07:58 PM, Mike Jones wrote:
> 1) Implementation & deployment status of the spec
> 
> Microsoft has at least four deployments of the specification.
> William Denniss has said that Google uses the specification.  I 
> believe that Ping Identity also uses it.  The specification is used by 
> https://tools.ietf.org/html/draft-ietf-oauth-token-binding-01 and 
> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-04.

Ciao
Hannes

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Shepherd writeup for OAuth 2.0 Authorization Server Metadata

2017-03-07 Thread Hannes Tschofenig

Hi Mike

thanks for the quick response and for the wording suggestions.

Regarding the implementations are OpenID Connect implementations
required to implement this functionality?

On 03/07/2017 07:58 PM, Mike Jones wrote:
> 1) Implementation & deployment status of the spec
> 
> Microsoft has at least four deployments of the specification.
> William Denniss has said that Google uses the specification.  I
> believe that Ping Identity also uses it.  The specification is used
> by https://tools.ietf.org/html/draft-ietf-oauth-token-binding-01 and
> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-04.

Ciao
Hannes



signature.asc
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Shepherd writeup for OAuth 2.0 Authorization Server Metadata

2017-03-07 Thread Mike Jones

Replies inline...

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Tuesday, March 7, 2017 10:46 AM
To: oauth@ietf.org; Phil Hunt 
Subject: [OAUTH-WG] Shepherd writeup for OAuth 2.0 Authorization Server Metadata

Hi all,

here is the write-up:
https://github.com/hannestschofenig/tschofenig-ids/blob/master/shepherd-writeups/Writeup_OAuth_Metadata.txt

I need your feedback on the following issues:

1) Implementation & deployment status of the spec

Microsoft has at least four deployments of the specification.  William Denniss 
has said that Google uses the specification.  I believe that Ping Identity also 
uses it.  The specification is used by 
https://tools.ietf.org/html/draft-ietf-oauth-token-binding-01 and 
https://tools.ietf.org/html/draft-ietf-oauth-device-flow-04.

2) Working group summary (see below)
(Particularly asking Phil whether this is a correct summary.)

Rather than saying "feedback resulted in significant restructuring of the 
document" I would say "feedback resulted in focusing the scope of the 
specification, removing everything except for the authorization server 
metadata, which remained unchanged".

3) There are four normative references to non-IETF specifications (see below). 
I am wondering whether these are indeed necessary (as normative references).

I believe that these normative references are all necessary, because they 
provide information necessary to implement normative portions of the 
specification.

4) Any other feedback?

Glad this is finishing!

Ciao
Hannes

Working Group Summary

   Work on a discovery mechanism for OAuth was planned since a long
   time but it took till late 2015 before a document was submitted
   to the group, which re-used work done in the OpenID Foundation.
   When the WGLC was started in 2016, see
   https://www.ietf.org/mail-archive/web/oauth/current/msg15796.html,
   feedback resulted in significant restructuring of the document.

   Now, almost a year later these concerns have been resolved and
   the document is ready for publication.

   [UNICODE]  The Unicode Consortium, "The Unicode Standard",
  .

   [USA15]Davis, M. and K. Whistler, "Unicode Normalization Forms",
  Unicode Standard Annex 15, June 2015,
  .

   [OAuth.Post]
  Jones, M. and B. Campbell, "OAuth 2.0 Form Post Response
  Mode", April 2015, .

   [OAuth.Responses]
  de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M.
  Jones, "OAuth 2.0 Multiple Response Type Encoding
  Practices", February 2014, 
.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Shepherd writeup for OAuth 2.0 Authorization Server Metadata

2017-03-07 Thread Hannes Tschofenig

Hi all,

here is the write-up:
https://github.com/hannestschofenig/tschofenig-ids/blob/master/shepherd-writeups/Writeup_OAuth_Metadata.txt

I need your feedback on the following issues:

1) Implementation & deployment status of the spec

2) Working group summary (see below)
(Particularly asking Phil whether this is a correct summary.)

3) There are four normative references to non-IETF specifications (see
below). I am wondering whether these are indeed necessary (as normative
references).

4) Any other feedback?

Ciao
Hannes

Working Group Summary

Work on a discovery mechanism for OAuth was planned since a long
time but it took till late 2015 before a document was submitted
to the group, which re-used work done in the OpenID Foundation.
When the WGLC was started in 2016, see
https://www.ietf.org/mail-archive/web/oauth/current/msg15796.html,
feedback resulted in significant restructuring of the document.

Now, almost a year later these concerns have been resolved and
the document is ready for publication.

[UNICODE] The Unicode Consortium, "The Unicode Standard",
.

[USA15]Davis, M. and K. Whistler, "Unicode Normalization Forms",
Unicode Standard Annex 15, June 2015,
.

[OAuth.Post]
Jones, M. and B. Campbell, "OAuth 2.0 Form Post Response
Mode", April 2015, .

[OAuth.Responses]
de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M.
Jones, "OAuth 2.0 Multiple Response Type Encoding
Practices", February 2014,
.

signature.asc
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)

2017-03-07 Thread Stephen Farrell



On 07/03/17 17:17, Mike Jones wrote:
> You're right, Stephen.  Re-reading the spec, it doesn't say that, and
> it should.  Sometimes it takes someone giving a spec a fresh read to
> uncover things that the authors understood and intended but failed to
> be captured in the text.  This is such a case - so thanks.
> 
> I'll add this information, which is necessary to understand the
> intent, and then republish.

Ah good, that explains the disconnect.

Cheers,
S.

> 
> -- Mike
> 
> -Original Message- From: Stephen Farrell
> [mailto:stephen.farr...@cs.tcd.ie] Sent: Monday, March 6, 2017 2:39
> PM To: Mike Jones ; Anthony Nadalin
> ; joel jaeggli ; The IESG
>  Cc: oauth-cha...@ietf.org;
> draft-ietf-oauth-amr-val...@ietf.org; oauth@ietf.org Subject: Re:
> [OAUTH-WG] Stephen Farrell's Discuss on
> draft-ietf-oauth-amr-values-05: (with DISCUSS)
> 
> 
> Hi Mike,
> 
> On 06/03/17 22:34, Mike Jones wrote:
>> Thanks for the reply, Stephen.  I'll try to find better 
>> interop-producing references where possible.
>> 
>> 
>> In some cases, however, the values are intentionally intended to 
>> provide an identifier for a family of closely-related methods, such
>> as "otp", which covers both time-based and HMAC-based OTPs.
> 
> Hmm. I don't recall text saying that in the draft, but it's possible
> that I missed it - can you point me at that?
> 
> I do agree that if the semantics here were "some otp was used" then
> it would not be necessary to specify exactly which OTP scheme was
> used. But that wasn't how I read what this spec was doing. (Again,
> that could be me getting the wrong end of the stick.)
> 
> S.
> 
> 
>> Many relying parties will be content to know that an OTP has been
>> used in addition to a password.  The distinction between which kind
>> of OTP was used is not useful to them.  Thus, there's a single
>> identifier that can be satisfied in two or more nearly equivalent
>> ways.  I consider this to be a feature - not a bug.
>> 
>> 
>> 
>> Similarly, there's a whole range of nuances between different 
>> fingerprint matching algorithms.  They differ in false positive and
>>  false negative rates over different population samples and also
>> differ based on the kind and model of fingerprint sensor used.
>> Like the OTP case, many RPs will be content to know that a
>> fingerprint match mas made, without delving into and
>> differentiating based on every aspect of the implementation of
>> fingerprint capture and match. Those that want more precision than
>> this can always define new "amr" values.  But "fpt" is fine as is
>> for what I believe will be the 90+% case.
>> 
>> 
>> 
>> Ultimately, the RP is depending upon the Identity Provider to do 
>> reasonable things.  If it didn't trust the IdP to do so, it has no
>>  business using it.  The "amr" value lets the IdP signal to the RP
>>  additional information about what it did, for the cases in which
>> that information is useful to the RP.
>> 
>> 
>> 
>> Reducing this to the point of absurdity, the RP would almost never
>>  care about the make, model, and serial number of the fingerprint 
>> reader or OTP.  Values could be defined to provide that
>> granularity. But making those fine-grained distinctions are not
>> useful in practice.
>> 
>> 
>> 
>> Please consider the existing definitions in light of that reductio
>> ad absurdum.  The existing values only make distinctions that are
>> known to be useful to RPs.  Slicing things more finely than would
>> be used in practice actually hurts interop, rather than helping it,
>> because it would force all RPs to recognize that several or many
>> different values actually mean the same thing to them.
>> 
>> 
>> 
>> -- Mike
>> 
>> 
>> 
>> -Original Message- From: Stephen Farrell 
>> [mailto:stephen.farr...@cs.tcd.ie] Sent: Monday, March 6, 2017 2:10
>> PM To: Mike Jones ; Anthony Nadalin 
>> ; joel jaeggli ; The IESG
>>   Cc: oauth-cha...@ietf.org; 
>> draft-ietf-oauth-amr-val...@ietf.org; oauth@ietf.org Subject: Re: 
>> [OAUTH-WG] Stephen Farrell's Discuss on 
>> draft-ietf-oauth-amr-values-05: (with DISCUSS)
>> 
>> 
>> 
>> 
>> 
>> Hi Mike,
>> 
>> 
>> 
>> Apologies - I updated the discuss ballot text [1] on Feb 28 but 
>> must've not sent it as an email or something. Anyway...
>> 
>> 
>> 
>> [1] 
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/ballot/
>>
>>
>>
>>
>> 
On 06/03/17 20:38, Mike Jones wrote:
>> 
>>> Hi Stephen.  The changes in draft -06 were intended to address
>>> your
>> 
>>> DISCUSS points.  Are you satisfied with these changes or are
>>> there
>> 
>>> additional changes you want?  I'm asking partly because it's a
>>> week
>> 
>>> now until the submission cutoff and if additional changes are
>>> needed,
>> 
>>> I'd like to make them this week.
>> 
>> 
>> 
>> So I do think there's still work to be done, may as well copy the
>> new ballot text here:
>> 
>> 
>> 
>> "
>> 
>> I think we still have the problem that the values "defined" here
>> (e.g. "fpt") are under specifi

Re: [OAUTH-WG] OAuth 2.0 Authorization Server Metadata: IPR Confirmation

2017-03-07 Thread Mike Jones

I am aware of no IPR encumbrances for this specification.

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Tuesday, March 7, 2017 10:02 AM
To: Hannes Tschofenig 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 Authorization Server Metadata: IPR 
Confirmation

I have no IPR disclosures to make.

John B.
> On Mar 7, 2017, at 2:50 PM, Hannes Tschofenig  
> wrote:
> 
> Hi John, Mike, Nat,
> 
> I am working on the shepherd writeup for the "OAuth 2.0 Authorization 
> Server Metadata" document:
> https://tools.ietf.org/html/draft-ietf-oauth-discovery-05
> 
> One item in the template requires me to indicate whether each document 
> author has confirmed that any and all appropriate IPR disclosures 
> required for full conformance with the provisions of BCP 78 and BCP 79 
> have already been filed.
> 
> Could you please confirm?
> 
> Ciao
> Hannes
> 
> 
> 
> ___
> 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 2.0 Authorization Server Metadata: IPR Confirmation

2017-03-07 Thread John Bradley

I have no IPR disclosures to make.

John B.
> On Mar 7, 2017, at 2:50 PM, Hannes Tschofenig  
> wrote:
> 
> Hi John, Mike, Nat,
> 
> I am working on the shepherd writeup for the "OAuth 2.0 Authorization
> Server Metadata" document:
> https://tools.ietf.org/html/draft-ietf-oauth-discovery-05
> 
> One item in the template requires me to indicate whether each document
> author has confirmed that any and all appropriate IPR disclosures
> required for full conformance with the provisions of BCP 78 and BCP 79
> have already been filed.
> 
> Could you please confirm?
> 
> Ciao
> Hannes
> 
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] OAuth 2.0 Authorization Server Metadata: IPR Confirmation

2017-03-07 Thread Hannes Tschofenig

Hi John, Mike, Nat,

I am working on the shepherd writeup for the "OAuth 2.0 Authorization
Server Metadata" document:
https://tools.ietf.org/html/draft-ietf-oauth-discovery-05

One item in the template requires me to indicate whether each document
author has confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79
have already been filed.

Could you please confirm?

Ciao
Hannes





signature.asc
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)

2017-03-07 Thread Mike Jones

You're right, Stephen.  Re-reading the spec, it doesn't say that, and it 
should.  Sometimes it takes someone giving a spec a fresh read to uncover 
things that the authors understood and intended but failed to be captured in 
the text.  This is such a case - so thanks.

I'll add this information, which is necessary to understand the intent, and 
then republish.

-- Mike

-Original Message-
From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] 
Sent: Monday, March 6, 2017 2:39 PM
To: Mike Jones ; Anthony Nadalin 
; joel jaeggli ; The IESG 

Cc: oauth-cha...@ietf.org; draft-ietf-oauth-amr-val...@ietf.org; oauth@ietf.org
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on 
draft-ietf-oauth-amr-values-05: (with DISCUSS)


Hi Mike,

On 06/03/17 22:34, Mike Jones wrote:
> Thanks for the reply, Stephen.  I'll try to find better 
> interop-producing references where possible.
> 
> 
> In some cases, however, the values are intentionally intended to 
> provide an identifier for a family of closely-related methods, such as 
> "otp", which covers both time-based and HMAC-based OTPs.

Hmm. I don't recall text saying that in the draft, but it's possible that I 
missed it - can you point me at that?

I do agree that if the semantics here were "some otp was used"
then it would not be necessary to specify exactly which OTP scheme was used. 
But that wasn't how I read what this spec was doing. (Again, that could be me 
getting the wrong end of the stick.)

S.


> Many
> relying parties will be content to know that an OTP has been used in 
> addition to a password.  The distinction between which kind of OTP was 
> used is not useful to them.  Thus, there's a single identifier that 
> can be satisfied in two or more nearly equivalent ways.  I consider 
> this to be a feature - not a bug.
> 
> 
> 
> Similarly, there's a whole range of nuances between different 
> fingerprint matching algorithms.  They differ in false positive and 
> false negative rates over different population samples and also differ 
> based on the kind and model of fingerprint sensor used.  Like the OTP 
> case, many RPs will be content to know that a fingerprint match mas 
> made, without delving into and differentiating based on every aspect 
> of the implementation of fingerprint capture and match.
> Those that want more precision than this can always define new "amr"
> values.  But "fpt" is fine as is for what I believe will be the 90+% 
> case.
> 
> 
> 
> Ultimately, the RP is depending upon the Identity Provider to do 
> reasonable things.  If it didn't trust the IdP to do so, it has no 
> business using it.  The "amr" value lets the IdP signal to the RP 
> additional information about what it did, for the cases in which that 
> information is useful to the RP.
> 
> 
> 
> Reducing this to the point of absurdity, the RP would almost never 
> care about the make, model, and serial number of the fingerprint 
> reader or OTP.  Values could be defined to provide that granularity.
> But making those fine-grained distinctions are not useful in practice.
> 
> 
> 
> Please consider the existing definitions in light of that reductio ad 
> absurdum.  The existing values only make distinctions that are known 
> to be useful to RPs.  Slicing things more finely than would be used in 
> practice actually hurts interop, rather than helping it, because it 
> would force all RPs to recognize that several or many different values 
> actually mean the same thing to them.
> 
> 
> 
> -- Mike
> 
> 
> 
> -Original Message- From: Stephen Farrell 
> [mailto:stephen.farr...@cs.tcd.ie] Sent: Monday, March 6, 2017 2:10 PM 
> To: Mike Jones ; Anthony Nadalin 
> ; joel jaeggli ; The IESG 
>  Cc: oauth-cha...@ietf.org; 
> draft-ietf-oauth-amr-val...@ietf.org; oauth@ietf.org Subject: Re:
> [OAUTH-WG] Stephen Farrell's Discuss on
> draft-ietf-oauth-amr-values-05: (with DISCUSS)
> 
> 
> 
> 
> 
> Hi Mike,
> 
> 
> 
> Apologies - I updated the discuss ballot text [1] on Feb 28 but 
> must've not sent it as an email or something. Anyway...
> 
> 
> 
> [1]
> https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/ballot/
> 
> 
> 
> On 06/03/17 20:38, Mike Jones wrote:
> 
>> Hi Stephen.  The changes in draft -06 were intended to address your
> 
>> DISCUSS points.  Are you satisfied with these changes or are there
> 
>> additional changes you want?  I'm asking partly because it's a week
> 
>> now until the submission cutoff and if additional changes are needed,
> 
>> I'd like to make them this week.
> 
> 
> 
> So I do think there's still work to be done, may as well copy the new 
> ballot text here:
> 
> 
> 
> "
> 
> I think we still have the problem that the values "defined" here (e.g. 
> "fpt") are under specified to a significant degree. RFC4949 does not 
> tell anyone how to achieve interop with "fpt" (nor any of the other 
> cases where you refer to 4949 I think). There is therefore no utility 
> in "defining" "fpt" as it will not

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-signed-http-request-03.txt

2017-03-07 Thread Justin Richer

What you describe as your minimum case is what I intended to be the 
minimum case for this document. I opted to put the token inside the 
payload instead of a hash because then we wouldn't need an additional 
header to carry the token, and the client wouldn't be required to do an 
additional crypto operation outside of the JOSE process.


 -- Justin


On 3/7/2017 2:13 AM, Nat Sakimura wrote:

Hi Justin, John, and Hannes

Is there an appetite to change the draft in such a way as:

- do not wrap access token itself. It could include at_hash though.
   Rationale: Pop access token can be pretty large and I do not want to
double base64url encode.
- perhaps change ts to string to accommodate nonce like string.

Essentially, what I want to do is not the http signing but just the pop
based
client authentication, which is very simple.
While I was writing it up, it occurred that if the above modification were
done, your draft will be a superset of what I wanted to do.

My write up is here: http://bit.ly/oauth-jpop

Financial API uses cases needs something like that.
(Another possibility is a sender confirmation.)

Best,

Nat Sakimura

--
PLEASE READ :This e-mail is confidential and intended for the
named recipient only. If you are not an intended recipient,
please notify the sender  and delete this e-mail.



-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of
internet-dra...@ietf.org
Sent: Tuesday, August 9, 2016 1:34 AM
To: i-d-annou...@ietf.org
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action:

draft-ietf-oauth-signed-http-request-03.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Web Authorization Protocol of the IETF.

 Title   : A Method for Signing HTTP Requests for OAuth
 Authors : Justin Richer
   John Bradley
   Hannes Tschofenig
Filename: draft-ietf-oauth-signed-http-request-03.txt
Pages   : 13
Date: 2016-08-08

Abstract:
This document a method for offering data origin authentication and
integrity protection of HTTP requests.  To convey the relevant data
items in the request a JSON-based encapsulation is used and the JSON
Web Signature (JWS) technique is re-used.  JWS offers integrity
protection using symmetric as well as asymmetric cryptography.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-request/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-signed-http-request-03


Please note that it may take a couple of minutes from the time of

submission

until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
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] I-D Action: draft-ietf-oauth-signed-http-request-03.txt

2017-03-07 Thread Nat Sakimura

Thanks Denis,

Yes. As currently specified, ts is an integer. My previous mail requested
it to be string instead so that I can used it as a nonce generated in the
style of H(timestamp|client_id|key) etc. I agree this is the place to
discuss replay protection etc. (Not in JAR, which is just a container
format.)

And, I have not yet posted oauth-jpop as an I-D :-) It is still in my repo
only and it has got more things to be done before it can be posted.
Hopefully, I can add more text and post it by Friday this week to make the
deadline for the next IETF.

Best,

Nat



On Tue, Mar 7, 2017 at 7:59 PM Denis  wrote:

> Hi Nat,
>
> I see that you are now back to the list.
>
> Please take note that "draft-ietf-oauth-signed-http-request-03.txt" has
> expired on February 9, 2017 .
>
> You said: "perhaps change ts to string to accommodate nonce like string"
>
> In this draft, ts is defined as:
>
>ts RECOMMENDED.  The timestamp.  This integer provides replay
>   protection of the signed JSON object.  Its value MUST be a number
>   containing an integer value representing number of whole integer
>   seconds from midnight, January 1, 1970 GMT.
>
> Section 7 is silent about replay protection and this is the single
> instance where "ts" is mentioned in the document.
>
> Hence it is rather hazy to understand how to deal with this value which is
> misnamed since it should rather be called:
> "iat" which means "Issued At".
>
> A "nonce" is a concept which does not exist in OAuth 2.0 documents (but
> which does exist in Open ID Connect documents).
>
> The core of the discussion is to explain how to achieve *replay
> protection of the signed JSON object*.
>
> I sent an email on Fri, 17 Feb 2017 21:51:18 +0100 with the following
> title :
> Re: [OAUTH-WG] Last Call: 
> (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request
> (JAR)) to Proposed Standard
> and *I got no response*.
>
> Please take a look at* ITEM 1* in the email from Friday, 17 February 2017
> which addresses replay protection of the signed JSON object
> and proposes a solution for OAuth 2.0 (which could be used as well by Open
> ID Connect).
>
> I take the opportunity of this email to comment on the individual draft
> you posted at:  http://bit.ly/oauth-jpop
> and which is called: draft-sakimura-oauth-jpop-00
>
> The Abstract states:
>
> Only the party *in possession of* a corresponding cryptographic key with
> the Jpop token can use it to get access
> to the associated resources unlike in the case of the bearer token
> described in [RFC6750]
> 
> where any party in
> possession of the access token can access the resource.
>
> The text should rather be changed into:
>
> Only the party *able to use* a corresponding cryptographic key with the
> Jpop token can use it to get access
> to the associated resources
>
> You know that in case of a collusion between clients, this method will be
> ineffective.
>
> Simply stating in the Security Considerations section "The client's secret
> key must be kept securely. " is insufficient.
>
> Also the text is speaking of a nonce which is not a value that has been
> registered by IANA.
>
>
> Denis
>
> Hi Justin, John, and Hannes
>
> Is there an appetite to change the draft in such a way as:
>
> - do not wrap access token itself. It could include at_hash though.
>   Rationale: Pop access token can be pretty large and I do not want to
>   double base64url encode.
> - perhaps change ts to string to accommodate nonce like string.
>
> Essentially, what I want to do is not the http signing but just the pop
> based client authentication, which is very simple.
>
> While I was writing it up, it occurred that if the above modification were
> done, your draft will be a superset of what I wanted to do.
>
> My write up is here: http://bit.ly/oauth-jpop
>
> Financial API uses cases needs something like that.
> (Another possibility is a sender confirmation.)
>
> Best,
>
> Nat Sakimura
>
> --
> PLEASE READ :This e-mail is confidential and intended for the
> named recipient only. If you are not an intended recipient,
> please notify the sender  and delete this e-mail.
>
>
>
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org ] On 
> Behalf ofinternet-dra...@ietf.org
> Sent: Tuesday, August 9, 2016 1:34 AM
> To: i-d-annou...@ietf.org
> Cc: oauth@ietf.org
> Subject: [OAUTH-WG] I-D Action:
>
> draft-ietf-oauth-signed-http-request-03.txt
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Web Authorization Protocol of the IETF.
>
> Title   : A Method for Signing HTTP Requests for OAuth
> Authors : Justin Richer
>   John Bradley
>   Hannes Tschofenig
>

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-signed-http-request-03.txt

2017-03-07 Thread Denis


Hi Nat,

I see that you are now back to the list.

Please take note that "draft-ietf-oauth-signed-http-request-03.txt" has 
expired on February 9, 2017 .


You said: "perhaps change ts to string to accommodate nonce like string"

In this draft, ts is defined as:

   ts RECOMMENDED.  The timestamp.  This integer provides replay
  protection of the signed JSON object.  Its value MUST be a number
  containing an integer value representing number of whole integer
  seconds from midnight, January 1, 1970 GMT.

Section 7 is silent about replay protection and this is the single 
instance where "ts" is mentioned in the document.


Hence it is rather hazy to understand how to deal with this value which 
is misnamed since it should rather be called:

"iat" which means "Issued At".

A "nonce" is a concept which does not exist in OAuth 2.0 documents (but 
which does exist in Open ID Connect documents).


The core of the discussion is to explain how to achieve *replay 
protection of the signed JSON object*.


I sent an email on Fri, 17 Feb 2017 21:51:18 +0100 with the following 
title :

Re: [OAUTH-WG] Last Call: 
(The OAuth 2.0 Authorization Framework: JWT Secured Authorization 
Request (JAR)) to Proposed Standard

and _I got no response_.

Please take a look at*ITEM 1* in the email from Friday, 17 February 2017 
which addresses replay protection of the signed JSON object
and proposes a solution for OAuth 2.0 (which could be used as well by 
Open ID Connect).


I take the opportunity of this email to comment on the individual draft 
you posted at: http://bit.ly/oauth-jpop

and which is called: draft-sakimura-oauth-jpop-00

The Abstract states:

   Only the party *in possession of* a corresponding cryptographic key
   with the Jpop token can use it to get access
   to the associated resources unlike in the case of the bearer token
   described in [RFC6750]
   

   where any party in
   possession of the access token can access the resource.

The text should rather be changed into:

   Only the party *able to use* a corresponding cryptographic key with
   the Jpop token can use it to get access
   to the associated resources

You know that in case of a collusion between clients, this method will 
be ineffective.


Simply stating in the Security Considerations section "The client's 
secret key must be kept securely. " is insufficient.


Also the text is speaking of a nonce which is not a value that has been 
registered by IANA.


Denis


Hi Justin, John, and Hannes

Is there an appetite to change the draft in such a way as:

- do not wrap access token itself. It could include at_hash though.
   Rationale: Pop access token can be pretty large and I do not want to
   double base64url encode.
- perhaps change ts to string to accommodate nonce like string.

Essentially, what I want to do is not the http signing but just the pop
based client authentication, which is very simple.

While I was writing it up, it occurred that if the above modification were
done, your draft will be a superset of what I wanted to do.

My write up is here: http://bit.ly/oauth-jpop

Financial API uses cases needs something like that.
(Another possibility is a sender confirmation.)

Best,

Nat Sakimura

--
PLEASE READ :This e-mail is confidential and intended for the
named recipient only. If you are not an intended recipient,
please notify the sender  and delete this e-mail.



-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of
internet-dra...@ietf.org
Sent: Tuesday, August 9, 2016 1:34 AM
To: i-d-annou...@ietf.org
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action:

draft-ietf-oauth-signed-http-request-03.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Web Authorization Protocol of the IETF.

 Title   : A Method for Signing HTTP Requests for OAuth
 Authors : Justin Richer
   John Bradley
   Hannes Tschofenig
Filename: draft-ietf-oauth-signed-http-request-03.txt
Pages   : 13
Date: 2016-08-08

Abstract:
This document a method for offering data origin authentication and
integrity protection of HTTP requests.  To convey the relevant data
items in the request a JSON-based encapsulation is used and the JSON
Web Signature (JWS) technique is re-used.  JWS offers integrity
protection using symmetric as well as asymmetric cryptography.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-request/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03

A diff from the previous version is a

Re: [OAUTH-WG] Updated Shepherd Write-Up for Native Apps document

2017-03-07 Thread Hannes Tschofenig

Hi Tony

thanks for the feedback. I have requested publication of the document a
few minutes ago already and we will incorporate any remarks from my
co-workers as part of the IETF-wide last call.

Ciao
Hannes

On 03/07/2017 09:17 AM, Anthony Nadalin wrote:
> I'm still getting feedback on the Windows examples that are pointed to by the 
> spec, since it's not a simple case on Windows 
> 
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
> Sent: Monday, March 6, 2017 8:00 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Updated Shepherd Write-Up for Native Apps document
> 
> Here is the shepherd write-up:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhannestschofenig%2Ftschofenig-ids%2Fblob%2Fmaster%2Fshepherd-writeups%2FWriteup_OAuth_NativeApps.txt&data=02%7C01%7Ctonynad%40microsoft.com%7C9a9ec9f090c74e34fb1a08d464a9e0a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244128165469063&sdata=olsSc81lMAqvlfAEBPCXY9CkIGv88W2Pt%2BkGj8yT2aY%3D&reserved=0
> 
> Feedback appreciated. I will also do another shepherd review.
> 
> Ciao
> Hannes
> 



signature.asc
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Updated Shepherd Write-Up for Native Apps document

2017-03-07 Thread Anthony Nadalin

I'm still getting feedback on the Windows examples that are pointed to by the 
spec, since it's not a simple case on Windows 

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Monday, March 6, 2017 8:00 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Updated Shepherd Write-Up for Native Apps document

Here is the shepherd write-up:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhannestschofenig%2Ftschofenig-ids%2Fblob%2Fmaster%2Fshepherd-writeups%2FWriteup_OAuth_NativeApps.txt&data=02%7C01%7Ctonynad%40microsoft.com%7C9a9ec9f090c74e34fb1a08d464a9e0a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244128165469063&sdata=olsSc81lMAqvlfAEBPCXY9CkIGv88W2Pt%2BkGj8yT2aY%3D&reserved=0

Feedback appreciated. I will also do another shepherd review.

Ciao
Hannes

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-native-apps-08.txt

2017-03-07 Thread Anthony Nadalin

Not true John, the CTAP support that is current would support the web-view w/o 
any changes 

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Monday, March 6, 2017 12:16 PM
To: Hannes Tschofenig 
Cc: internet-dra...@ietf.org; oauth@ietf.org
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-native-apps-08.txt

On fido I can tell you that for security reasons U2F wont work from a web-view 
currently.

Once we move to Web Auth (Fido 2) where the OS provides a API for apps to call 
to get the token it will work but the tokens are audianced to the app based on 
its developer key and bundle_id so that a app cant ask for a token for a 
different site to do correlation. 

It is true that Fido UAF currently requires a web-view to work as the 
authenticator is effectively compiled in to each application, and that 
application has access to the private keys on most platforms (Samsung knox 
being the only exception to that that I know of where the keys are managed by a 
common API to hardware key storage, but they are scoped like U2F as well)

So for the most part it is true and that unless you use the browser to get the 
Fido token the audience is for the app.
Example  Salesforce creates native app that may use enterprise SSO via SAML, 
and the enterprise may use Fido as a authentication factor.
If they use the webview + fido API approach the app can only get a token for 
SalesForce based on its signing key.  It could fire up the web-view and do U2F 
authentication with the enterprise after Salesforec has redirected the user.  
However it will give every enterprise a token audience to Salesforce with a 
salesforce specific key.   If there is a second app for say Slack if they do 
the same thing the enterprise would get a slack audienced token and a slack key 
forcing a separate registration. 

The recommended alternative is that the app use a custom tab for the user to 
SalesForce and that redirect to the enterprise.
The enterprise gets the same token/key with the correct audience from all apps 
on the device using the browser or custom tab. 
The user may not need to signin a second time, and if they do there Fido token 
will not need to be re-registerd.

The Fido API approach really only works for first party apps like PayPal if the 
the app is not doing federation and paypal is doing the authentication for 
there own app.

Token binding private keys have similar issues.   The pool of private keys will 
probably not be shared between apps, and not between the app and the browser 
(Win 10 may be an exception but it is not documented yet)

In the case of using AppAuth with token binding the browser maintains the keys 
so the enterprise would be able to see the same key and use the same cookies 
across all AppAuth Apps.

You can include token binding in your app, however the token bindings and 
cookies are going to be sand boxed per app.  
Depending on implementation the app gets access to the cookie, but perhaps not 
to the private token binding key.  (At least I don't think it will in Android 
embedded webview).

We could expand on this later in an update to the BCP once Web Authentication 
and Token Binding are final.

There are still some unknowns, but in general for any sort of SSO/Federation 
3rd party app I don’t see recommending anything other than a custom tab/ view 
controller/ external browser.

William can take the formatting question:)

John B.
> On Mar 6, 2017, at 4:41 PM, Hannes Tschofenig  
> wrote:
> 
> Hi William, Hi John,
> 
> I just re-read version -8 of the document again.
> 
> Two minor remarks only.
> 
> Editorial issue: Why do you need to introduce a single sub-section 
> within Section 7.1. (namely Section 7.1.1)?
> 
> Background question: You note that embedded user agents have the 
> disadvantage that the app that hosts the embedded user-agent can 
> access the user's full authentication credential. This is certainly 
> true for password-based authentication mechanisms but I wonder whether 
> this is also true for strong authentication techniques, such as those 
> used by FIDO combined with token binding. Have you looked into more 
> modern authentication techniques as well and their security implication?
> 
> Ciao
> Hannes
> 
> On 03/03/2017 07:39 AM, William Denniss wrote:
>> Changes:
>> 
>> – Addresses feedback from the second round of WGLC.
>> – Reordered security consideration sections to better group related topics.
>> – Added complete URI examples to each of the 3 redirect types.
>> – Editorial pass.
>> 
>> 
>> 
>> On Thu, Mar 2, 2017 at 10:27 PM, > > wrote:
>> 
>> 
>>A New Internet-Draft is available from the on-line Internet-Drafts
>>directories.
>>This draft is a work item of the Web Authorization Protocol of the IETF.
>> 
>>Title   : OAuth 2.0 for Native Apps
>>Authors : William Denniss
>>  John Bradley
>>

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-native-apps-08.txt

Re: [OAUTH-WG] Shepherd writeup for OAuth 2.0 Authorization Server Metadata

Re: [OAUTH-WG] Shepherd writeup for OAuth 2.0 Authorization Server Metadata

Re: [OAUTH-WG] Shepherd writeup for OAuth 2.0 Authorization Server Metadata

[OAUTH-WG] Shepherd writeup for OAuth 2.0 Authorization Server Metadata

Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)

Re: [OAUTH-WG] OAuth 2.0 Authorization Server Metadata: IPR Confirmation

Re: [OAUTH-WG] OAuth 2.0 Authorization Server Metadata: IPR Confirmation

[OAUTH-WG] OAuth 2.0 Authorization Server Metadata: IPR Confirmation

Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-signed-http-request-03.txt

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-signed-http-request-03.txt

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-signed-http-request-03.txt

Re: [OAUTH-WG] Updated Shepherd Write-Up for Native Apps document

Re: [OAUTH-WG] Updated Shepherd Write-Up for Native Apps document

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-native-apps-08.txt

16 matches

Site Navigation

Mail list logo

Footer information