Re: [OAUTH-WG] FW: Call for consensus on SPICE charter

[nadalin]

JWT and CWT registries to enable digital credentials to transition from one 
security format to another (i.e., JSON/CBOR).
*   A proposed standard document defining SD-CWT, a profile of CWT inspired 
by SD-JWT (from OAuth) that enables digital credentials with unlinkability and 
selective disclosure.
*   A proposed standard Metadata Discovery protocol using HTTPS/CoAP for 
CBOR-based digital credentials to enable the 3 roles (issuers, holders and 
verifiers) to discover supported protocols and formats for keys, claims, 
credential types and proofs. The design will be inspired by the OAuth 
"vc-jwt-issuer" metadata work (draft-ietf-oauth-sd-jwt-vc 
<https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/> ) which supports 
ecosystems using JSON serialization.

Milestones

*   04-2025 - Submit an informational Architecture document to the IESG for 
publication
*   10-2025 - Submit a proposed standard document covering a JWP/CWP 
profile for digital credentials to the IESG for publication
*   10-2025 - Submit a proposed standard document defining SD-CWT to the 
IESG for publication
*   03-2026 - Submit a document as a proposed standard covering Metadata 
Discovery to the IESG for publication

 <https://datatracker.ietf.org/doc/charter-ietf-spice/00-00/#introduction> 
Introduction

 <https://datatracker.ietf.org/doc/charter-ietf-spice/00-00/#goal> Goal

 <https://datatracker.ietf.org/doc/charter-ietf-spice/00-00/#program-of-work> 
Program of Work

 <https://datatracker.ietf.org/doc/charter-ietf-spice/00-00/#milestones> 
Milestones

 

 

 

 

From: Orie Steele mailto:orie@transmute.industries> 
> 
Sent: Monday, February 19, 2024 6:15 PM
To: Anthony Nadalin mailto:nada...@prodigy.net> >
Cc: Roman Danyliw mailto:r...@cert.org> >; oauth 
mailto:oauth@ietf.org> >
Subject: Re: [OAUTH-WG] FW: Call for consensus on SPICE charter

 

Inline:

On Mon, Feb 19, 2024, 7:34 PM mailto:nada...@prodigy.net> 
> wrote:

Orie, thanks for the response

 

I’m still confused on this charter proposal as I read this charter it is to 
create architecture, patterns and definitions for electronic credentials. The 
charter should be free of any technology including W3C, if people want clarity 
about what an electronic credential is then they can help out with the 
definitions since that is an output, so I don’t agree with how W3C is mentioned 
in the charter. 

 

As you pointed out below, W3C has defined credentials that are simply public 
keys bound to an origin (used as authenticators), and issuer signed claims 
about a subject (like JWTs)

 

So far the people who have been most active seem interested in generalizing the 
"signed public key and attributes" version of a digital credential. That 
definition lines up well with JWT and CWT with the cnf claim, and mDoc (as I 
understand it).

 

Most of the value W3C VC Data Model provides is focused on creating a structure 
for the claims that go in the credential. The security of W3C VCs based on JWT, 
SD-JWT, and COSE comes from the IETF drafts not from W3C.

 

Some of the protocol connection points also come from IETF documents, for 
example aud, nonce and cnf.

 

Most of the value JWT and CWT provide, is through the public claims and private 
claims in the associated IANA registries. For example, this is where the cnf 
claim that ties proof of possession to credentials is registered.

 

It's my understanding that mdocs have a namespace approach to claims as well.

 

Creating conventions for claims in a credential format is profiling. iso mdoc 
is a profile of COSE Sign1 in that sense.

 

You can consider the W3C documents that rely on JWT, CWT and COSE as profiles 
of those IETF standards. Instead of using JWT or CWT claimsets, the W3C uses 
JSON-LD.

 

A major reason for spice forming was to explore alternative claims structures, 
and to align CWT and JWT conventions for credentials that DO NOT require 
JSON-LD.

 

The way I read the charter is that interested parties will work on various 
profiles to map/profile various technologies to the create architecture, 
patterns and definitions documents, this will be done with various members that 
submit drafts.

 

Relative to WebAuthn what is produced is a credential, its not a JWT or SD-JWT 
but as the charter reads that is not the only credentials under consideration, 
if this is the case then the charter severely lacks clarity on what is the goal.

 

I don't think there is utility in IETF creating a profile for webauthn based 
credentials, because they are not meant to be presented beyond the origin they 
are bound to.

 

 

ISO is just another standards org, W3C, OIDF, OASIS, etc work with ISO with no 
issues, I assume profile will be created by various members that submit drafts, 
if no one is interested in mDL/ISO then that’s fine.

 

I still think this charter needs more clarity as I point out

 

Can you su

Re: [OAUTH-WG] FW: Call for consensus on SPICE charter

[nadalin]

SG for 
publication
*   10-2025 - Submit a proposed standard document covering a JWP/CWP 
profile for digital credentials to the IESG for publication
*   10-2025 - Submit a proposed standard document defining SD-CWT to the 
IESG for publication
*   03-2026 - Submit a document as a proposed standard covering Metadata 
Discovery to the IESG for publication

 <https://datatracker.ietf.org/doc/charter-ietf-spice/00-00/#introduction> 
Introduction

 <https://datatracker.ietf.org/doc/charter-ietf-spice/00-00/#goal> Goal

 <https://datatracker.ietf.org/doc/charter-ietf-spice/00-00/#program-of-work> 
Program of Work

 <https://datatracker.ietf.org/doc/charter-ietf-spice/00-00/#milestones> 
Milestones

 

 

 

 

From: Orie Steele  
Sent: Monday, February 19, 2024 6:15 PM
To: Anthony Nadalin 
Cc: Roman Danyliw ; oauth 
Subject: Re: [OAUTH-WG] FW: Call for consensus on SPICE charter

 

Inline:

On Mon, Feb 19, 2024, 7:34 PM mailto:nada...@prodigy.net> 
> wrote:

Orie, thanks for the response

 

I’m still confused on this charter proposal as I read this charter it is to 
create architecture, patterns and definitions for electronic credentials. The 
charter should be free of any technology including W3C, if people want clarity 
about what an electronic credential is then they can help out with the 
definitions since that is an output, so I don’t agree with how W3C is mentioned 
in the charter. 

 

As you pointed out below, W3C has defined credentials that are simply public 
keys bound to an origin (used as authenticators), and issuer signed claims 
about a subject (like JWTs)

 

So far the people who have been most active seem interested in generalizing the 
"signed public key and attributes" version of a digital credential. That 
definition lines up well with JWT and CWT with the cnf claim, and mDoc (as I 
understand it).

 

Most of the value W3C VC Data Model provides is focused on creating a structure 
for the claims that go in the credential. The security of W3C VCs based on JWT, 
SD-JWT, and COSE comes from the IETF drafts not from W3C.

 

Some of the protocol connection points also come from IETF documents, for 
example aud, nonce and cnf.

 

Most of the value JWT and CWT provide, is through the public claims and private 
claims in the associated IANA registries. For example, this is where the cnf 
claim that ties proof of possession to credentials is registered.

 

It's my understanding that mdocs have a namespace approach to claims as well.

 

Creating conventions for claims in a credential format is profiling. iso mdoc 
is a profile of COSE Sign1 in that sense.

 

You can consider the W3C documents that rely on JWT, CWT and COSE as profiles 
of those IETF standards. Instead of using JWT or CWT claimsets, the W3C uses 
JSON-LD.

 

A major reason for spice forming was to explore alternative claims structures, 
and to align CWT and JWT conventions for credentials that DO NOT require 
JSON-LD.

 

The way I read the charter is that interested parties will work on various 
profiles to map/profile various technologies to the create architecture, 
patterns and definitions documents, this will be done with various members that 
submit drafts.

 

Relative to WebAuthn what is produced is a credential, its not a JWT or SD-JWT 
but as the charter reads that is not the only credentials under consideration, 
if this is the case then the charter severely lacks clarity on what is the goal.

 

I don't think there is utility in IETF creating a profile for webauthn based 
credentials, because they are not meant to be presented beyond the origin they 
are bound to.

 

 

ISO is just another standards org, W3C, OIDF, OASIS, etc work with ISO with no 
issues, I assume profile will be created by various members that submit drafts, 
if no one is interested in mDL/ISO then that’s fine.

 

I still think this charter needs more clarity as I point out

 

Can you suggest text?

 

 

From: Orie Steele mailto:orie@transmute.industries> 
> 
Sent: Friday, February 16, 2024 10:11 AM
To: nada...@prodigy.net <mailto:nada...@prodigy.net> 
Cc: Roman Danyliw mailto:r...@cert.org> >; oauth 
mailto:oauth@ietf.org> >
Subject: Re: [OAUTH-WG] FW: Call for consensus on SPICE charter

 

Hey Tony,

 

On Thu, Feb 15, 2024 at 1:36 PM mailto:nada...@prodigy.net> > wrote:

1) Do you support the charter text? Or do you have objections or blocking 
concerns (please describe what they might be and how you would propose 
addressing the concern)?

Not sure I support at this point, I understand the need for an architecture 
document with patterns and definitions, etc. 

There is a lot of work going on outside the IETF in this area such as the mDL 
work in ISO that already has patterns and definitions along with credential 
formats (mdoc)  and transports (ble/http/nfc). I don’t believe the IETF should 
ignore these efforts since most of the driving licence and passport 

Re: [OAUTH-WG] FW: Call for consensus on SPICE charter

[nadalin]

Orie, thanks for the response

 

I’m still confused on this charter proposal as I read this charter it is to 
create architecture, patterns and definitions for electronic credentials. The 
charter should be free of any technology including W3C, if people want clarity 
about what an electronic credential is then they can help out with the 
definitions since that is an output, so I don’t agree with how W3C is mentioned 
in the charter. The way I read the charter is that interested parties will work 
on various profiles to map/profile various technologies to the create 
architecture, patterns and definitions documents, this will be done with 
various members that submit drafts.

 

Relative to WebAuthn what is produced is a credential, its not a JWT or SD-JWT 
but as the charter reads that is not the only credentials under consideration, 
if this is the case then the charter severely lacks clarity on what is the goal.

 

ISO is just another standards org, W3C, OIDF, OASIS, etc work with ISO with no 
issues, I assume profile will be created by various members that submit drafts, 
if no one is interested in mDL/ISO then that’s fine.

 

I still think this charter needs more clarity as I point out

 

 

From: Orie Steele  
Sent: Friday, February 16, 2024 10:11 AM
To: nada...@prodigy.net
Cc: Roman Danyliw ; oauth 
Subject: Re: [OAUTH-WG] FW: Call for consensus on SPICE charter

 

Hey Tony,

 

On Thu, Feb 15, 2024 at 1:36 PM mailto:nada...@prodigy.net> > wrote:

1) Do you support the charter text? Or do you have objections or blocking 
concerns (please describe what they might be and how you would propose 
addressing the concern)?

Not sure I support at this point, I understand the need for an architecture 
document with patterns and definitions, etc. 

There is a lot of work going on outside the IETF in this area such as the mDL 
work in ISO that already has patterns and definitions along with credential 
formats (mdoc)  and transports (ble/http/nfc). I don’t believe the IETF should 
ignore these efforts since most of the driving licence and passport 
communities/companies are adopting this as one of the standards that issuers 
and verifiers will use. The same is true for W3C WebAuthn.


WebAuthN cannot produce standard digital signatures, and so it cannot be used 
to produce standard digital credentials (for example it cannot be used to 
produce JWT or SD-JWT).
It could produce authentications for public keys that could be bound to 
credentials, but because of the origin binding in WebAuthN, this would not fit 
well with the "audience" typically used for digital credentials (usually there 
is no audience)

You might find this thread on possible relation between mDoc and CWT 
interesting:

https://mailarchive.ietf.org/arch/msg/spice/xiRpmd-Bexv94qentlGg1Snjw1A/


The architecture, patterns and definitions should be free from technology, I 
don't know why W3C is mentioned in the introduction as the only technology, 
this should not be in the introduction but along with other technologies such 
as mDL/mdoc, webauthn, etc when describing profiles. As the goal would be for 
interested parties to produce profiles of other technologies to fit the 
architecture document with patterns and definitions.


W3C is mentioned because some W3C members asked for a term other than 
"Verifiable Credentials" to be used... and they asserted the "Verifiable 
Credentials" implies the JSON-LD data model developed in W3C.

ISO was not emphasized because formal coordination would require contribution 
from ISO experts, and we have had relatively low engagement from them.
 


I believe that the WG if formed should also think about holder verification and 
patterns and attestations that can be used.

 

Interesting. I think this is covered under the metadata discovery deliverable, 
but if you feel it could be made more clear, please send text.

 

Also there needs to be a notion of a "reader/wallet/etc" that can potentially 
store credentials (not necessarily the user or verifier) and release/store 
credentials upon "user" consent.


This sounds like an application to me.
How do you see this related to "credential formats" or "issuer/holder/verifier 
metadata"?
 



There are other models than the 3 party that VCs use, so these also need to be 
considered in the architecture,  patterns and definitions documents to enable 
profiles for other technologies.


Agreed, OAuth JWTs/SD-JWTs, and ISO mDocs are examples we have discussed.
Are there others you would like to see considered?  



I believe in the 1st 3 items in Goals but  I don't believe it would be in the 
best interest to define a metatdata protocol, as this sounds like this would be 
a protocol for obtaining DID documents, there are already many protocols out 
there for metadata retrieval, not sure there is a need for another one, if one 
is needed for DIDs then that may be better done in W3C as this does not seem to 
fit well with the charter


Discovering attestations for 

Re: [OAUTH-WG] FW: Call for consensus on SPICE charter

[nadalin]

1) Do you support the charter text? Or do you have objections or blocking 
concerns (please describe what they might be and how you would propose 
addressing the concern)?

Not sure I support at this point, I understand the need for an architecture 
document with patterns and definitions, etc. 

There is a lot of work going on outside the IETF in this area such as the mDL 
work in ISO that already has patterns and definitions along with credential 
formats (mdoc)  and transports (ble/http/nfc). I don’t believe the IETF should 
ignore these efforts since most of the driving licence and passport 
communities/companies are adopting this as one of the standards that issuers 
and verifiers will use. The same is true for W3C WebAuthn.

The architecture, patterns and definitions should be free from technology, I 
don't know why W3C is mentioned in the introduction as the only technology, 
this should not be in the introduction but along with other technologies such 
as mDL/mdoc, webauthn, etc when describing profiles. As the goal would be for 
interested parties to produce profiles of other technologies to fit the 
architecture document with patterns and definitions.

I believe that the WG if formed should also think about holder verification and 
patterns and attestations that can be used. Also there needs to be a notion of 
a "reader/wallet/etc" that can potentially store credentials (not necessarily 
the user or verifier) and release/store credentials upon "user" consent. 

There are other models than the 3 party that VCs use, so these also need to be 
considered in the architecture,  patterns and definitions documents to enable 
profiles for other technologies. 

I believe in the 1st 3 items in Goals but  I don't believe it would be in the 
best interest to define a metatdata protocol, as this sounds like this would be 
a protocol for obtaining DID documents, there are already many protocols out 
there for metadata retrieval, not sure there is a need for another one, if one 
is needed for DIDs then that may be better done in W3C as this does not seem to 
fit well with the charter

This charter seems to be very scoped to W3C technology, I understand that 
interested parties will have to contribute if they want to have other 
technologies included but the charter in general does not seem to allow this, 
so removing specific technology will allow this to happen. 

I would be happy to give provide specific text changes to the charter.


2) If you do support the charter text:


3) Are you willing to author or participate in the developed of the WG drafts?

yes

• Are you willing to review the WG drafts?

yes

• Are you interested in implementing the WG drafts?

I'm willing to see how we can use these outputs with the other industry 
technologies.



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

Re: [OAUTH-WG] Call for Adoption: DPoP

[Anthony Nadalin]

+1

From: OAuth  On Behalf Of Mike Jones
Sent: Tuesday, March 17, 2020 8:14 AM
To: Rifaat Shekh-Yusef ; oauth 
Subject: [EXTERNAL] Re: [OAUTH-WG] Call for Adoption: DPoP

I am for adoption of DPoP.

   -- Mike

From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Rifaat Shekh-Yusef
Sent: Tuesday, March 17, 2020 5:21 AM
To: oauth mailto:oauth@ietf.org>>
Subject: [OAUTH-WG] Call for Adoption: DPoP

All,

As per the conclusion of the PoP interim meeting, this is a call for adoption 
for the OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer 
(DPoP) document:
https://datatracker.ietf.org/doc/draft-fett-oauth-dpop/

Please, let us know if you support or object to the adoption of this document 
as a working group document by March 31st.

Regards,
 Rifaat & Hannes
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [EXTERNAL] OAuth 2.1: dropping password grant

[Anthony Nadalin]

I would suggest a SHOULD NOT instead of MUST, there are still sites using this 
and a grace period should be provided before a MUST is pushed out as there are 
valid use cases out there still.

From: OAuth  On Behalf Of Dick Hardt
Sent: Tuesday, February 18, 2020 12:37 PM
To: oauth@ietf.org
Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password grant

Hey List

(Once again using the OAuth 2.1 name as a placeholder for the doc that Aaron, 
Torsten, and I are working on)

In the security topics doc

https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2.4

The password grant MUST not be used.

Some background for those interested. I added this grant into OAuth 2.0 to 
allow applications that had been provided password to migrate. Even with the 
caveats in OAuth 2.0, implementors decide they want to prompt the user to enter 
their credentials, the anti-pattern OAuth was created to eliminate.


Does anyone have concerns with dropping the password grant from the OAuth 2.1 
document so that developers don't use it?

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

Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop

[Anthony Nadalin]

I know you were too polite !

From: Steinar Noem 
Sent: Saturday, August 10, 2019 11:04 AM
To: Nat Sakimura 
Cc: Anthony Nadalin ; Mike Jones 
; OAuth WG 
Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop

That is good to hear, Nat.
I tried to be as polite as possible in my response.

lør. 10. aug. 2019 kl. 10:52 skrev Nat Sakimura 
mailto:sakim...@gmail.com>>:
I think Tony was just joking as it was quite a hassle for both of us to get to 
Gjøvik for an ISO meeting.

On Thu, Aug 8, 2019 at 9:50 PM Steinar Noem 
mailto:stei...@udelt.no>> wrote:
Hey Anthony. Gjøvik is part of NTNU, we are waiting for feedback from them :)

I think Trondheim is more accessible (travel time) and has more to offer.

tor. 8. aug. 2019 kl. 14:42 skrev Anthony Nadalin 
mailto:40microsoft@dmarc.ietf.org>>:
How about the University in Gjovik ?
Get Outlook for Android<https://aka.ms/ghei36>


From: OAuth mailto:oauth-boun...@ietf.org>> on behalf 
of Daniel Fett mailto:danielf%2boa...@yes.com>>
Sent: Wednesday, August 7, 2019 11:47:51 PM
To: Dick Hardt mailto:dick.ha...@gmail.com>>; 
dba...@leastprivilege.com<mailto:dba...@leastprivilege.com> 
mailto:dba...@leastprivilege.com>>
Cc: Mike Jones 
mailto:40microsoft@dmarc.ietf.org>>;
 OAuth WG mailto:oauth@ietf.org>>

Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop

Not yet, we are talking to potential venues. It's vacation time in Norway right 
now, so that will take a week or two more.

-Daniel

Am 07.08.19 um 18:09 schrieb Dick Hardt:
Are we ready to pick a date?

On Thu, Jul 25, 2019 at 11:30 PM Dominick Baier 
mailto:dba...@leastprivilege.com>> wrote:
August will conflict with holiday time for most Europeans…

Just been to Trondheim last week - it was lovely weather.

———
Dominick


On 25. July 2019 at 22:14:28, Mike Jones 
(michael.jones=40microsoft@dmarc.ietf.org<mailto:michael.jones=40microsoft@dmarc.ietf.org>)
 wrote:
I'm not aware of any conflicts for any of the three sets of dates.

-- Mike

-Original Message-
From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Aaron Parecki
Sent: Thursday, July 25, 2019 4:07 PM
To: Dick Hardt mailto:dick.ha...@gmail.com>>
Cc: OAuth WG mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop

We'll be so productive with only 4 hours of darkness every day!

All of the dates work for me, but I would prefer the July dates since it'll be 
easier/cheaper to bundle the two trips into one. (Hopefully we could get the 
OAuth meeting dates early in the week at IETF then)

On Thu, Jul 25, 2019 at 3:37 PM Dick Hardt 
mailto:dick.ha...@gmail.com>> wrote:
>
> +1 to July / August. Nicer weather in the north then. =)
>
> On Thu, Jul 25, 2019 at 11:56 AM Daniel Fett 
> mailto:danielf%2boa...@yes.com>> wrote:
>>
>> Hi all,
>>
>> it seems like there is a rough consensus on having the next OAuth Security 
>> Workshop in Trondheim, Norway. We will therefore start with the planning.
>>
>> After checking various event calendars it seems like the following dates are 
>> suitable:
>>
>> May 7-9
>>
>> July 22-24
>>
>> August 3-5
>>
>> First date is before EIC ‘20 which is May 12-15 in Munich/Germany. The 
>> latter two dates are before/after IETF 108 which is July 25-31, Madrid/Spain.
>>
>> Unless somebody raises objections because of conflicting identity/security 
>> events we will pick one of these dates in the next two weeks or so
>>
>> -Daniel
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org<mailto:OAuth@ietf.org>
>> https://www
>> .ietf.org<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.org=02%7C01%7Ctonynad%40microsoft.com%7C24500550fdb347a700f808d71dbd3661%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637010570831332090=DdWZCoppTjVZTdtgt%2FER7N59HHmcKEslU8zJYwCBz0Q%3D=0>%2Fmailman%2Flistinfo%2Foauthdata=02%7C01%7CMichael.Jon
>> es%40microsoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com=02%7C01%7Ctonynad%40microsoft.com%7C24500550fdb347a700f808d71dbd3661%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637010570831342083=QwDmcdAgVzCSD2jWgLgbc%2BpPMld3dVwoGUyuk5HlfT4%3D=0>%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f14
>> 1af91ab2d7cd011db47%7C1%7C0%7C636996821305207975sdata=dAokWYxwGW
>> SRXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3Dreserved=0
>
> ___
> OAuth mailing list
> OAuth@ietf.org<mailto:OAuth@ietf.org>
> https://www.
> ietf.org<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.org

Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop

[Anthony Nadalin]

How about the University in Gjovik ?

Get Outlook for Android


From: OAuth  on behalf of Daniel Fett 

Sent: Wednesday, August 7, 2019 11:47:51 PM
To: Dick Hardt ; dba...@leastprivilege.com 

Cc: Mike Jones ; OAuth WG 

Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop

Not yet, we are talking to potential venues. It's vacation time in Norway right 
now, so that will take a week or two more.

-Daniel

Am 07.08.19 um 18:09 schrieb Dick Hardt:
Are we ready to pick a date?

On Thu, Jul 25, 2019 at 11:30 PM Dominick Baier 
mailto:dba...@leastprivilege.com>> wrote:
August will conflict with holiday time for most Europeans…

Just been to Trondheim last week - it was lovely weather.

———
Dominick


On 25. July 2019 at 22:14:28, Mike Jones 
(michael.jones=40microsoft@dmarc.ietf.org)
 wrote:

I'm not aware of any conflicts for any of the three sets of dates.

-- Mike

-Original Message-
From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Aaron Parecki
Sent: Thursday, July 25, 2019 4:07 PM
To: Dick Hardt mailto:dick.ha...@gmail.com>>
Cc: OAuth WG mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop

We'll be so productive with only 4 hours of darkness every day!

All of the dates work for me, but I would prefer the July dates since it'll be 
easier/cheaper to bundle the two trips into one. (Hopefully we could get the 
OAuth meeting dates early in the week at IETF then)

On Thu, Jul 25, 2019 at 3:37 PM Dick Hardt 
mailto:dick.ha...@gmail.com>> wrote:
>
> +1 to July / August. Nicer weather in the north then. =)
>
> On Thu, Jul 25, 2019 at 11:56 AM Daniel Fett 
> mailto:danielf%2boa...@yes.com>> wrote:
>>
>> Hi all,
>>
>> it seems like there is a rough consensus on having the next OAuth Security 
>> Workshop in Trondheim, Norway. We will therefore start with the planning..
>>
>> After checking various event calendars it seems like the following dates are 
>> suitable:
>>
>> May 7-9
>>
>> July 22-24
>>
>> August 3-5
>>
>> First date is before EIC ‘20 which is May 12-15 in Munich/Germany. The 
>> latter two dates are before/after IETF 108 which is July 25-31, Madrid/Spain.
>>
>> Unless somebody raises objections because of conflicting identity/security 
>> events we will pick one of these dates in the next two weeks or so.
>>
>> -Daniel
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
>> .ietf.org%2Fmailman%2Flistinfo%2Foauthdata=02%7C01%7CMichael.Jon
>> es%40microsoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f14
>> 1af91ab2d7cd011db47%7C1%7C0%7C636996821305207975sdata=dAokWYxwGW
>> SRXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3Dreserved=0
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Foauthdata=02%7C01%7CMichael.Jones
> %40microsoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af
> 91ab2d7cd011db47%7C1%7C0%7C636996821305207975sdata=dAokWYxwGWSRXy
> rzs4V%2BWMXcMD482nhyARt28me4xbE%3Dreserved=0

___
OAuth mailing list
OAuth@ietf.org

Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens

[Anthony Nadalin]

I support adoption of this draft as a working group document with the following 
caveats:

1. These are not to be used as ID Tokens/authentication tokens 
2. The privacy issues must be addressed 
3. Needs to be extensible, much like ID-Token, can't be 100% fixed 


-Original Message-
From: OAuth  On Behalf Of Hannes Tschofenig
Sent: Monday, April 8, 2019 10:07 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens

Hi all,

this is the call for adoption of the 'JWT Usage in OAuth2 Access Tokens'  
document following the positive feedback at the last IETF meeting in Prague.

Here is the document:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-bertocci-oauth-access-token-jwt-00data=02%7C01%7Ctonynad%40microsoft.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636903400616347061sdata=ePmwaD%2FHCRZhRx%2FwZbb3U72%2FhBalPoFPKtQ67QTxIRw%3Dreserved=0

Please let us know by April 22nd whether you accept / object to the adoption of 
this document as a starting point for work in the OAuth working group.

Ciao
Hannes & Rifaat

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

___
OAuth mailing list
OAuth@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauthdata=02%7C01%7Ctonynad%40microsoft.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636903400616357060sdata=zcxw1IR3kNbuZ9u58OOJDv9pLb7cUCooDtlIUH7tS%2Fw%3Dreserved=0

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

Re: [OAUTH-WG] Call for adoption of "JWT Response for OAuth Token Introspection"

[Anthony Nadalin]

I’m concerned over the security implications of a client being able to 
introspect a token, for bearer tokens this can be very problematic, so unless 
the issues with possible token theft can be addressed I don’t support this as a 
WG draft

From: OAuth  On Behalf Of Rifaat Shekh-Yusef
Sent: Thursday, July 19, 2018 10:44 AM
To: oauth 
Subject: [OAUTH-WG] Call for adoption of "JWT Response for OAuth Token 
Introspection"

Hi all,

This is the call for adoption of the 'JWT Response for OAuth Token 
Introspection' document following the presentation by Torsten at the Montreal 
IETF meeting where we didn't have a chance to do a call for adoption in the 
meeting itself.

Here is presentation by Torsten:
https://datatracker.ietf.org/meeting/102/materials/slides-102-oauth-sessa-jwt-response-for-oauth-token-introspection-00

Here is the document:
https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-response-01

Please let us know by August 2nd whether you accept / object to the adoption of 
this document as a starting point for work in the OAuth working group.

Regards,
Hannes & Rifaat
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Meeting Invite for the OAuth WG Virtual Office Hours

[Anthony Nadalin]

I was dialed in and no one was there

From: OAuth  On Behalf Of Hannes Tschofenig
Sent: Monday, June 18, 2018 2:06 PM
To: Brian Campbell 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Meeting Invite for the OAuth WG Virtual Office Hours

Rifaat was on the call for 30mins but nobody joined. I couldn’t make it due to 
a delayed flight.

Write-ups are in progress.

Ciao
Hannes


From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: 18 June 2018 18:47
To: Hannes Tschofenig
Cc: mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Meeting Invite for the OAuth WG Virtual Office Hours

I tried to join this morning but was the only one on the webex (of course, user 
error could be involved on my part).

I didn't have much specific for the call but did want to politely ask the 
Chairs how the document shepherding was coming along for 
https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/
 ?



On Wed, May 16, 2018 at 11:38 AM, Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>> wrote:
Hi all,

Rifaat and I will again dial into the Webex next Monday to hear whether someone 
of you has anything to discuss/report/suggest/….

Ciao
Hannes & Rifaat
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

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


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately by 
e-mail and delete the message and any file attachments from your computer. 
Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Token Binding Presentations?

[Anthony Nadalin]

I'm unaware of any support for "OAuth" Token Binding from Microsoft, so I 
assume you are talking just about Token Binding cookies

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Friday, March 17, 2017 10:43 AM
To: Jim Manico 
Cc: IETF OAUTH 
Subject: Re: [OAUTH-WG] Token Binding Presentations?

This has some of the basic info, but needs some updating.   
http://www.browserauth.net/

Other than that there are the specs in the Token binding WG and the one we just 
updated for OAuth.

With Microsoft supporting it in RS2 coming out in a month or so I would hope to 
see some developer documentation from them soon.

John B.

On Mar 17, 2017, at 12:09 PM, Jim Manico 
> wrote:

Hello OAuthers,

I'm trying to get my head around token binding beyond the RFC. Are there any 
presentations or other media on token binding that any of you are aware of? My 
google-fu is coming up empty.

Thanks and Aloha,
- Jim
___
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] Updated Shepherd Write-Up for Native Apps document

[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=02%7C01%7Ctonynad%40microsoft.com%7C9a9ec9f090c74e34fb1a08d464a9e0a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244128165469063=olsSc81lMAqvlfAEBPCXY9CkIGv88W2Pt%2BkGj8yT2aY%3D=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] Call for adoption: OAuth Security Topics

[Anthony Nadalin]

I would be in favor of this 

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Wednesday, February 1, 2017 11:10 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Call for adoption: OAuth Security Topics

Hi all,

this is the call for adoption of the 'OAuth Security Topics' document following 
the positive call for adoption at the last IETF meeting in Seoul.

Here is the document:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-lodderstedt-oauth-security-topics-00=02%7C01%7Ctonynad%40microsoft.com%7Cdd2d04df662a4bfe36e508d44b3a84e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636216162098338101=9tMjjKtTBQrNVEEpwfMaIH2gTymyADdgjEJnKU4MP6U%3D=0

The intention with this document is to have a place to collect discussions and 
conclusions around OAuth 2.0 security and to reference the actual solution 
specifications.

Please let us know by Feb 16th whether you accept / object to the adoption of 
this document as a starting point for work in the OAuth working group.

Ciao
Hannes & Derek

___
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)

[Anthony Nadalin]

We have interoped between FIDO authenticators vendors and Windows Hello

-Original Message-
From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] 
Sent: Wednesday, February 1, 2017 4:24 PM
To: Mike Jones <michael.jo...@microsoft.com>; Anthony Nadalin 
<tony...@microsoft.com>; joel jaeggli <joe...@bogus.com>; The IESG 
<i...@ietf.org>
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)



On 02/02/17 00:21, Mike Jones wrote:
> Thanks, Tony.  I can add that reference.
> 
> Stephen, the sets of initial values were chosen from those used in
> practice by Microsoft and Google in real deployments.

Genuine questions: do you aim to have interop between those
deployments? What if I wanted to write code that'd interop
with msft or google?

S.

> 
> About "otp", there are existing use cases for indicating that an OTP
> was used.  I'm not aware of any of these use cases where the
> distinction between TOTP and HOTP is important.  Thus, having "otp"
> now makes sense, where having "hotp" and "totp" now doesn't.
> 
> Stephen, this may seem like splitting hairs, but the registry
> instructions for "Specification Document(s)" are about having a
> reference for the document where the Authentication Method Reference
> Name (such as "otp") is defined.  In all cases for the initial
> values, this is the RFC-to-be, so the registry instructions are
> satisfied.  If someone were, for instance, to define the string
> "hotp", it would be incumbent on the person requesting its
> registration to provide a URL to the document where the string "hotp"
> is defined.  Also having a reference to RFC 4226 in that document
> would be a good thing, but that isn't what the registry instructions
> are about.
> 
> All that said, I can look at also finding appropriate references for
> the remaining values that don't currently have them.  (Anyone got a
> good reference for password or PIN to suggest, for instance?)
> 
> -- Mike
> 
> -Original Message- From: Anthony Nadalin Sent: Wednesday,
> February 1, 2017 4:10 PM To: Stephen Farrell
> <stephen.farr...@cs.tcd.ie>; Mike Jones
> <michael.jo...@microsoft.com>; joel jaeggli <joe...@bogus.com>; The
> IESG <i...@ietf.org> 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)
> 
> NIST asked for the addition of IRIS (as they are seeing more use of
> IRIS over retina due to the accuracy of iris)  as they have been
> doing significant testing on various iris devices and continue to do
> so, here is a report that NIST released
> http://2010-2014.commerce.gov/blog/2012/04/23/nist-iris-recognition-report-evaluates-needle-haystack-search-capability.html
> 
> 
> -Original Message- From: Stephen Farrell
> [mailto:stephen.farr...@cs.tcd.ie] Sent: Wednesday, February 1, 2017
> 2:26 PM To: Mike Jones <michael.jo...@microsoft.com>; joel jaeggli
> <joe...@bogus.com>; The IESG <i...@ietf.org> 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 01/02/17 17:00, Mike Jones wrote:
>> Thanks for the discussion, Stephen.
>> 
>> To your point about "otp", the working group discussed this very 
>> point.  They explicitly decided not to introduce "hotp" and "totp" 
>> identifiers because no one had a use case in which the distinction 
>> mattered.
> 
> Then I'm not following why adding "otp" to the registry now is a good
> plan.
> 
> If there's a use-case now, then adding an entry with a good reference
> to the relevant spec seems right.
> 
> If there's no use-case now, then not adding it to the registry seems
> right. (Mentioning it as a possible future entry would be fine.)
> 
> I think the same logic would apply for all the values that this spec
> adds to the registry. Why is that wrong?
> 
>> Others can certainly introduce those identifiers and register them
>> if they do have such a use case, once the registry has been
>> established.  But the working group wanted to be conservative about
>> the identifiers introduced to prime the registry, and this is such
>> a case.
>> 
>> What identifiers to use and register will always be a balancing
>> act. You want to be as specific as necessary to add practical an

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

[Anthony Nadalin]

The code point is that Windows Hello protocol supports three types of biometric 
authentication: fingerprint, face and iris, we need to distinguish between eye, 
retina and iris. There are windows devices that do retina also, like windows 
phones, we have now gone to iris after the NIST testing and thus want tto make 
sure there is a way to distinguish during the  authentication since the iris 
scan reduces the probability of error

-Original Message-
From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] 
Sent: Wednesday, February 1, 2017 4:15 PM
To: Anthony Nadalin <tony...@microsoft.com>; Mike Jones 
<michael.jo...@microsoft.com>; joel jaeggli <joe...@bogus.com>; The IESG 
<i...@ietf.org>
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 Tony,

On 02/02/17 00:10, Anthony Nadalin wrote:
> NIST asked for the addition of IRIS (as they are seeing more use of
> IRIS over retina due to the accuracy of iris)  as they have been
> doing significant testing on various iris devices and continue to do
> so, here is a report that NIST released
> http://2010-2014.commerce.gov/blog/2012/04/23/nist-iris-recognition-report-evaluates-needle-haystack-search-capability.html
> 

Sorry, but that doesn't help me (at first glance anyway). If
there's a reference that'd garner us interop, then great, just
add it to match the codepoint. If there's not, I don't see why
adding a codepoint is useful. (Esp. if we're at the stage of
testing "various iris devices" that I would guess do not get
us interop.)

Am I missing something?

Cheers,
S.

> 
> -Original Message- From: Stephen Farrell
> [mailto:stephen.farr...@cs.tcd.ie] Sent: Wednesday, February 1, 2017
> 2:26 PM To: Mike Jones <michael.jo...@microsoft.com>; joel jaeggli
> <joe...@bogus.com>; The IESG <i...@ietf.org> 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 01/02/17 17:00, Mike Jones wrote:
>> Thanks for the discussion, Stephen.
>> 
>> To your point about "otp", the working group discussed this very 
>> point.  They explicitly decided not to introduce "hotp" and "totp" 
>> identifiers because no one had a use case in which the distinction 
>> mattered.
> 
> Then I'm not following why adding "otp" to the registry now is a good
> plan.
> 
> If there's a use-case now, then adding an entry with a good reference
> to the relevant spec seems right.
> 
> If there's no use-case now, then not adding it to the registry seems
> right. (Mentioning it as a possible future entry would be fine.)
> 
> I think the same logic would apply for all the values that this spec
> adds to the registry. Why is that wrong?
> 
>> Others can certainly introduce those identifiers and register them
>> if they do have such a use case, once the registry has been
>> established.  But the working group wanted to be conservative about
>> the identifiers introduced to prime the registry, and this is such
>> a case.
>> 
>> What identifiers to use and register will always be a balancing
>> act. You want to be as specific as necessary to add practical and
>> usable value, but not so specific as to make things unnecessarily
>> brittle.
> 
> Eh... don't we want interop? Isn't that the primary goal here?
> 
>> While some might say there's a difference between serial number 
>> ranges of particular authentication devices, going there is
>> clearly in the weeds.  On the other hand, while there used to be an
>> "eye" identifier, Elaine Newton of NIST pointed out that there are 
>> significant differences between retina and iris matching, so "eye" 
>> was replaced with "retina" and "iris".  Common sense informed by 
>> actual data is the key here.
> 
> That's another good example. There's no reference for "iris." If that
> is used in some protocol, then what format(s) are expected to be
> supported? Where do I find that spec? If we can answer that, then
> great, let's add the details. If not, then I'd suggest we omit "iris"
> and leave it 'till later to add an entry for that. And again,
> including text with "iris" as an example is just fine, all I'm asking
> is that we only add the registry entry if we can meet the same bar
> that we're asking the DE to impose on later additions.
> 
> And the same for all the others...
> 
> Cheers, S.
> 
> 
>> 
>>

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

[Anthony Nadalin]

NIST asked for the addition of IRIS (as they are seeing more use of IRIS over 
retina due to the accuracy of iris)  as they have been doing significant 
testing on various iris devices and continue to do so, here is a report that 
NIST released 
http://2010-2014.commerce.gov/blog/2012/04/23/nist-iris-recognition-report-evaluates-needle-haystack-search-capability.html
  

-Original Message-
From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] 
Sent: Wednesday, February 1, 2017 2:26 PM
To: Mike Jones ; 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 01/02/17 17:00, Mike Jones wrote:
> Thanks for the discussion, Stephen.
> 
> To your point about "otp", the working group discussed this very
> point.  They explicitly decided not to introduce "hotp" and "totp"
> identifiers because no one had a use case in which the distinction
> mattered.  

Then I'm not following why adding "otp" to the registry now
is a good plan.

If there's a use-case now, then adding an entry with a good
reference to the relevant spec seems right.

If there's no use-case now, then not adding it to the
registry seems right. (Mentioning it as a possible future
entry would be fine.)

I think the same logic would apply for all the values that
this spec adds to the registry. Why is that wrong?

> Others can certainly introduce those identifiers and
> register them if they do have such a use case, once the registry has
> been established.  But the working group wanted to be conservative
> about the identifiers introduced to prime the registry, and this is
> such a case.
> 
> What identifiers to use and register will always be a balancing act.
> You want to be as specific as necessary to add practical and usable
> value, but not so specific as to make things unnecessarily brittle.

Eh... don't we want interop? Isn't that the primary goal here?

> While some might say there's a difference between serial number
> ranges of particular authentication devices, going there is clearly
> in the weeds.  On the other hand, while there used to be an "eye"
> identifier, Elaine Newton of NIST pointed out that there are
> significant differences between retina and iris matching, so "eye"
> was replaced with "retina" and "iris".  Common sense informed by
> actual data is the key here.

That's another good example. There's no reference for "iris." If
that is used in some protocol, then what format(s) are expected
to be supported? Where do I find that spec? If we can answer that,
then great, let's add the details. If not, then I'd suggest we
omit "iris" and leave it 'till later to add an entry for that.
And again, including text with "iris" as an example is just fine,
all I'm asking is that we only add the registry entry if we can
meet the same bar that we're asking the DE to impose on later
additions.

And the same for all the others...

Cheers,
S.


> 
> The point of the registry requiring a specification reference is so
> people using the registry can tell where the identifier is defined.
> For all the initial values, that requirement is satisfied, since the
> reference will be to the new RFC.  I think that aligns with the point
> that Joel was making.
> 
> Your thoughts?
> 
> -- Mike
> 
> -Original Message- From: OAuth
> [mailto:oauth-boun...@ietf.org] On Behalf Of Stephen Farrell Sent:
> Wednesday, February 1, 2017 7:03 AM To: 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)
> 
> 
> 
> On 01/02/17 14:58, joel jaeggli wrote:
>> On 1/31/17 8:26 AM, Stephen Farrell wrote:
>>> Stephen Farrell has entered the following ballot position for 
>>> draft-ietf-oauth-amr-values-05: Discuss
>>> 
>>> When responding, please keep the subject line intact and reply to
>>> all email addresses included in the To and CC lines. (Feel free
>>> to cut this introductory paragraph, however.)
>>> 
>>> 
>>> Please refer to 
>>> https://www.ietf.org/iesg/statement/discuss-criteria.html for
>>> more information about IESG DISCUSS and COMMENT positions.
>>> 
>>> 
>>> The document, along with other ballot positions, can be found
>>> here: 
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
>>> 
>>> 
>>> 
>>> -
>>>
>>> 
-
>>> DISCUSS: 
>>> -
>>>
>>> 
-
>>> 
>>> This specification seems to me to break it's own rules. You state
>>>  that registrations should include a reference to a specification
>>> to improve interop. And yet, for the strings added here (e.g.
>>> otp) you don't do that (referring 

Re: [OAUTH-WG] Future of PoP Work

[Anthony Nadalin]

I would like to see us proceed with the symmetric PoP work in Oauth WG and stop 
the HTTP Signing work all together

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Wednesday, October 19, 2016 12:54 PM
To: Hannes Tschofenig 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Future of PoP Work

In my opinion, at this time, the OAuth WG should not proceed with the symmetric 
implementation of PoP and should not continue work on HTTP signing.

On Wed, Oct 19, 2016 at 12:45 PM, Hannes Tschofenig 
> wrote:
Hi all,

two questions surfaced at the last IETF meeting, namely

1) Do we want to proceed with the symmetric implementation of PoP or,
alternatively, do we want to move it over to the ACE working group?

2) Do we want to continue the work on HTTP signing?

We would appreciate your input on these two questions.

Ciao
Hannes & Derek


___
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] Authentication Method Reference Values Document: IPR Confirmation

[Anthony Nadalin]

I’m not aware of any IPR

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt (IDM)
Sent: Tuesday, September 20, 2016 8:54 PM
To: Mike Jones 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Authentication Method Reference Values Document: IPR 
Confirmation

I am aware of no IPR.

Phil

On Sep 19, 2016, at 2:26 AM, Mike Jones 
> wrote:
I am aware of no IPR on this specification.

   -- Mike

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Monday, September 19, 2016 2:21 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Authentication Method Reference Values Document: IPR 
Confirmation

Hi Mike, Phil, Tony,


I am working on the shepherd writeup for the AMR document:
https://tools.ietf.org/html/draft-ietf-oauth-amr-values-02

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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Following up on token exchange use case

[Anthony Nadalin]

Things have gotten so muddled not sure where to begin, the original goal of 
this draft was to provide the function that we use in daily high volume 
production of WS-Trust as we transition to Oauth.  WS-Trust provided many 
options, one was ActAs and the other was OnBehalfOf, these were 2 distinct 
functions but could be combined (and thus the results are of a composite 
nature). There were also other options like delegateTo, Forwardable and 
Delegatable. So we have use cases for all these.

So we have straight forward scenarios for (1) a token request to be on behalf 
of a given/specified token, we also have a straight forward scenario for (2) 
requesting a token based upon a specific token. We also have complex scenarios 
for combining the semantics of both  (1) and (2) where the token request is on 
behalf of a specific token and the request is based upon a specific token, this 
happened a lot in our server to server scenarios for access to backend 
documents and services. Where we have chained services this is where the 
delegateTo, Forwardable and Delegatable options come into the scenario.

The way that this current specification is structured and written the Subject 
is always required which is a not a good thing since there may not be a 
subject, as basic token requests don’t have to have subjects (just 
authentication credentials), thus you can’t get the semantics of (2) without 
(1). Now the semantics of combing (1) and (2) seem to be not understood and 
wanting to be removed.


From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer
Sent: Saturday, August 27, 2016 3:26 PM
To: Brian Campbell 
Cc:  
Subject: Re: [OAUTH-WG] Following up on token exchange use case

No objections. Simplification is better, and this spec is already fairly 
convoluted with all the options turned on.

 — Justin

On Aug 26, 2016, at 1:30 PM, Brian Campbell 
> wrote:

Looking for two things here:
1) Any objections to removing the want_composite request parameter? Please 
explain, if so. I plan to remove it in the next draft barring an outpouring of 
support to keep it.
2) Tony to explain his use case and describe what changes would be needed to 
accommodate it.

On Mon, Aug 1, 2016 at 2:00 PM, Brian Campbell 
> wrote:
During the meeting in Berlin Tony voiced concern about a use case he had for 
token exchange. Honestly, it's still not entirely clear to me what that use 
case is or what would need to change in support of it. I'd like to better 
understand the use case and see if it's something that can reasonably be 
accommodated with Token Exchange. During the meeting Tony referred back to an 
earlier email where he said, "want_composite is not really the effect we are 
looking for since it provides for a single token, the use case we have is where 
you want the ability to use the subject_token and the actor_token in 
combination and not as a composite of only the claims."
The want_composite parameter came about during some iterative work on the 
document (between I-D publications) last year. At first the client could 
express that it wanted a composite token, one containing delegation semantics, 
with the inclusion of the actor_token parameter. One of the other editors 
suggested, however, that the actor_token token might be necessary for 
authorization in cases even when the client wasn't asking for a composite token 
and that placing the desire for delegation semantics on it was overloading the 
parameter too much. I introduced the want_composite parameter to give the 
client such a signal independent of the actor_token parameter. My (admittedly 
incomplete) understanding of WS-Trust is that the client/requester can make 
such an indication and I was trying to follow that model. However, I'm not sure 
it's needed or even makes much much sense. Ultimately it's the server's 
decision about how to construct the issued token and what to include in it. It 
is the server's policy, not a client signal, which makes the determination. So 
the want_composite parameter is really just noise that makes the spec longer. 
And, from the quote above, seems might also lead some readers to incorrect 
conclusions about what can and cannot be returned in a token exchange.
I'd propose then that the want_composite parameter be dropped from the document.


___
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] Call for adoption: Token Binding for OAuth 2.0

[Anthony Nadalin]

I’m OK with the 
https://tools.ietf.org/html/draft-jones-oauth-token-binding-00
 but not sure that 
https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00
 is a good starting point as we would want a more generic solution for PoP 
tokens in general


From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Tuesday, August 16, 2016 11:45 AM
To: Hannes Tschofenig 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Call for adoption: Token Binding for OAuth 2.0

Just a friendly reminder that the 'deadline' for this call for adoption is 
tomorrow.

According to the minutes from 
Berlin,
 13 people were in favor of adopting OAuth 2.0 Token Binding and 0 were against.

On Wed, Aug 3, 2016 at 1:45 AM, Hannes Tschofenig 
> wrote:
Hi all,

this is the call for adoption of the 'OAuth 2.0 Token Binding' document
bundle* following the positive call for adoption at the recent IETF
meeting in Berlin.

Here are the links to the documents presented at the last IETF meeting:
https://tools.ietf.org/html/draft-jones-oauth-token-binding-00
https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00

Please let us know by August 17th whether you accept / object to the
adoption of this document as a starting point for work in the OAuth
working group.

Ciao
Hannes & Derek

*: We will find out what the best document structure is later, i.e.,
whether the content should be included in one, two or multiple documents.


___
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 Security -- Next Steps

[Anthony Nadalin]

Sounds about right, but I would imagine that the BCP would cover any issue that 
arises not just mix-up

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Monday, July 25, 2016 3:59 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] OAuth Security -- Next Steps

Hi all,

We had two working group sessions at the Berlin IETF meeting and I am happy 
about the progress on many of the subjects. We managed to progress token 
exchange, native apps, AMR, and authorization server meta-data. We also 
identified new use cases to explore with the device flow document.

We also did a call for adoption of the OAuth token binding functionality, which 
still needs to be confirmed on the mailing list.
(Further emails will follow.)

There are, however, aspects I am not happy with. I was hoping to make some 
progress on the mix-up mitigation and on the wider range of security documents.

Here is how I see the story after talking to some meeting participants.

1) It seems that the solution approach to deal with the mix-up attack (only 
mix-up) described in draft-ietf-oauth-mix-up-mitigation-01 needs to be modified 
to reflect the preference of the working group. My impression (from speaking 
with participants at the meeting last week
privately) is that there is interest in a solution that does not require 
protocol changes but rather relies on configuration. This may include a 
combination of exact redirect_URI matching + per-AS redirect_URI + session 
state checking. There are also other attacks described in 
draft-ietf-oauth-mix-up-mitigation-01, which need to be moved elsewhere to 
avoid confusion.

2) We need a new document, ideally a BCP, that serves as a high-level write-up 
describing various security issues with OAuth that points to the mostly 
existing documents for those who want to read the background information. 
Torsten has posted a mail to the list providing one possible outline of such a 
document.

How does this sound?

Ciao
Hannes

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

Re: [OAUTH-WG] RT treatment in Token Exchange

[Anthony Nadalin]

So I think the proposed wording is still too specific and limits the use case , 
I also don’t understand the usage of “credential” in your description as this 
does not have to be a credential. So suggest that this be simple and if you 
want you can explain in the security considerations section why one may not 
want to return a refresh_token

OPTIONAL.  The refresh_token for the issued token in the token_exchange request

access_token (response), this does not have to be an access_token so this is a 
bad name


Also it’s unclear why the subject_token is required, is it being suggested that 
the subject_token is also being used as an access_token ? The actor_token if 
specified could also be the subject_token

The term “security_token” I assume is not limited to access_token since there 
is a subject_token_type.

want_composite is not really the effect we are looking for since it provides 
for a single token, the use case we have is where you want the ability to use 
the subject_token and the actor_token in combination and not as a composite of 
only the claims.

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Tuesday, July 5, 2016 11:16 AM
To: oauth 
Subject: [OAUTH-WG] RT treatment in Token Exchange

I gave a short presentation about OAuth 2.0 Token 
Exchange
 at a recent identity conference, which seemed well received and a lot of folks 
expressed their support for it and a desire to see support for it in offerings 
out in the wild.
However, I did get some feedback from Vittorio Bertocci of Microsoft that he 
felt that the language around issuing refresh tokens was overly restrictive 
based on real world deployment experience they have with a token exchange like 
interaction that they are currently offering. He described it as follows:
"To summarize our main use case: we use [a token exchange like protocol] for 
achieving user impersonation thru tiers, or delegation for confidential clients 
which do not have any web UX.

Those cases do call for the ability of the middle tier to access the resource 
also when the original credential is no longer valid (e.g. there is no longer 
any user entertaining an active session with the middle tier).

Think of a hypothetical new feature of the Uber mobile app, which can monitor 
your Exchange calendar and book a ride whenever a suitable slot opens up within 
a certain time range. The Uber app would call an Uber-owned middle tier, in 
form of Web API, and the Web API would itself be a client of the Exchange API. 
Given that the Uber API doesn’t offer any browser ready surface, as it is meant 
to be accessed only via oauth2 bearer token, the [token exchange] is the only 
way through which it can obtain a token for the Exchange API; and the scenario 
definitely call for offline access, as the uber API should be able to monitor 
the Exchange calendar of the user even if the user closed the app on his/her 
phone."

While the current text in the draft allows for this kind of thing, it 
stigmatizes it somewhat with a "NOT RECOMMENDED" on sending an RT in the 
response. So the proposal here is to make refresh tokens OPTIONAL and change 
the accompanying text in sec 2.2.1 to the following:

   refresh_token
  OPTIONAL.  A refresh token will typically not be issued when the
  the exchange is of one temporary credential (the subject_token)
  for a different temporary credential (the issued token) for use in
  some other context.  A refresh token can be issued in cases where
  the client of the token exchange needs the ability to access a
  resource even when the original credential is no longer valid
  (e.g. user-not-present or offline scenarios where there is no
  longer any user entertaining an active session with the client).
  Profiles or deployments of this specification should clearly
  document the conditions under which a client should expect a
  refresh token in response to "urn:ietf:params:oauth:grant-
  type:token-exchange" grant type requests.
I plan to make the aforementioned change and get a new draft published with 
that and some other updates later this week before the Internet Draft 
submission cut-off on Friday.



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

Re: [OAUTH-WG] closing an open issue about supplementary info in the Token Exchange request

[Anthony Nadalin]

Sounds appropriate

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Monday, June 20, 2016 10:16 AM
To: oauth 
Subject: [OAUTH-WG] closing an open issue about supplementary info in the Token 
Exchange request

A good while back in an off list conversation about Token Exchange, Chuck 
Mortimore mentioned that they "had a use-case for custom claims in where they 
essentially wanted to carry along metadata about a client or device for 
association to objects in our cloud." As a result of that conversation I added 
the bullet item to the Open Issues section that says, "Provide a way to include 
supplementary claims or information in the request that would/could potentially 
be included in the issued token.", which has just been kinda sitting there ever 
since with no action being taken on it.
I recently had the opportunity to see Chuck present about some work that they 
are doing for IoT, which utilizes a number of items from this WG including 
Token Exchange. It turns out that they were able to accommodate that use-case 
of expressing metadata about a client or device by using the actor_token.  
There's a paper about the work at 
https://www.salesforceidentity.info/Using_Asset_Tokens.pdf
 if anyone is interested in more details.
Because the use-case behind that open issue is met by the existing constructs 
of the document, I'm proposing that no new parameters or tokens be introduced 
and that the open issue be removed and considered done in the next revision of 
the Token Exchange draft. Please speak up soon, if you believe this is a 
mistake.

Thanks,
Brian



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

Re: [OAUTH-WG] Reminder: OAuth Security Workshop

[Anthony Nadalin]

Can I also suggest that a PayPal or Credit Card payment be added as a means as 
bank transfer for corporate folks is like impossible 

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
Sent: Monday, May 16, 2016 4:25 AM
To: Hannes Tschofenig ; oauth@ietf.org; Daniel Fett 

Subject: Re: [OAUTH-WG] Reminder: OAuth Security Workshop

I'm planning to submit a position paper to the OAuth security workshop.  I 
couldn't find any guidance on what the program committee is looking for in the 
papers.  I could imagine anything from submitting a paragraph or two describing 
the conversations I'd like to lead to a 10-page paper suitable for 
peer-reviewed publication, or anything in between.  What were you looking for?

Also, will the position papers be published in a workshop proceedings or will 
they be used only for determining who will be invited to participate?

Thanks,
-- Mike

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Monday, May 16, 2016 3:31 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Reminder: OAuth Security Workshop

Hi all,

this is a reminder that the call for position paper deadline for the OAuth 
Security Workshop is getting closer.

Here is the link to the info:
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2finfsec.uni-trier.de%2fevents%2fosw2016=01%7c01%7ctonynad%40microsoft.com%7c17bb7f6c7065422371df08d37d7cd18b%7c72f988bf86f141af91ab2d7cd011db47%7c1=NOKnwv9A439uCCz89MtiIDSjQZGNlUNo4zXibDGwotI%3d

Ciao
Hannes

___
OAuth mailing list
OAuth@ietf.org
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth=01%7c01%7ctonynad%40microsoft.com%7c17bb7f6c7065422371df08d37d7cd18b%7c72f988bf86f141af91ab2d7cd011db47%7c1=2ARrqLXQ5QQ7d8gvrm%2bqaXmyXrhl3Q10kOc7X5usag4%3d

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

Re: [OAUTH-WG] Multi-AS State Re-Use

[Anthony Nadalin]

STATE can be anything, it does not have to be a NONCE so changing this would 
cause issues at this time for existing deployments

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura
Sent: Monday, May 9, 2016 7:34 PM
To: Guido Schmitz ; oauth@ietf.org
Subject: Re: [OAUTH-WG] Multi-AS State Re-Use

As far as I am aware of, state was meant to be nonce. Replay possibility etc. 
were known. It is probably a bad documentation that every reviewers missed 
because they were assuming it.

Best,

Nat
On Mon, May 9, 2016 at 20:14 Guido Schmitz 
> wrote:
Hi all,

can anybody confirm that this is a new / undocumented attack?

Cheers,

Guido, Daniel, and Ralf

On 22.04.2016 16:23, Daniel Fett wrote:
> Hi all,
>
> Besides the state leakage attack we found that another important fact
> regarding state is underspecified: Each state value should only be
> used for one run of the protocol, in particular, each AS should see a
> different state in multi-AS settings. Clients might be tempted to
> generate state once and then re-use each time a user wants to
> authorize.
>
> If state is re-used, given a setup where one Client allows users to
> authorize using two AS, a potentially malicious AS learns the state
> value that is valid for authorization at an honest AS. I.e., each AS
> can mount a CSRF attack on the user using the other AS.
>
> Just as the attack in the other mail, this is not a big deal in
> practice, but should be discussed somewhere.
>
> Cheers,
> Daniel, Guido, and Ralf
>

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura
Chairman of the Board, OpenID Foundation
Trustee, Kantara Initiative
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0

[Anthony Nadalin]

Specifications should be somewhat complete and not open ended/not thought out, 
you should think about the issues, requirements and use cases first before you 
try to force this into the working group process and confuse people , we had 
too many of these specifications lately.

We are now up to 15+ specifications that someone has to read and understand how 
these all may or may not fit together and all the interactions that may occur. 
So much for the simple Oauth.

From: Justin Richer [mailto:jric...@mit.edu]
Sent: Tuesday, April 12, 2016 5:46 AM
To: Torsten Lodderstadt <tors...@lodderstedt.net>
Cc: Anthony Nadalin <tony...@microsoft.com>; <oauth@ietf.org> <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0

+1 to Torsten’s point.

And a reminder to Tony that call for adoption is the *start* of the document 
editing process, not the end. We’re not saying this is a complete solution with 
everything thought out when we adopt the document, we’re saying it’s a problem 
we want to work on and a direction that we want to move in. Stop trying to 
confuse people.

 — Justin

On Apr 12, 2016, at 1:30 AM, Torsten Lodderstedt 
<tors...@lodderstedt.net<mailto:tors...@lodderstedt.net>> wrote:

Indicating the resource server to the AS allows the AS to automatically select 
token type, encryption scheme and user data to be put into the access token 
based on a RS-specific policy. So there is no need to explicitely ask the AS 
for a certain token format or encryption scheme.

Am 11.04.2016 um 22:35 schrieb Anthony Nadalin 
<tony...@microsoft.com<mailto:tony...@microsoft.com>>:
So it’s an incomplete solution then ?

From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Monday, April 11, 2016 1:34 PM
To: Anthony Nadalin <tony...@microsoft.com<mailto:tony...@microsoft.com>>
Cc: Nat Sakimura <sakim...@gmail.com<mailto:sakim...@gmail.com>>; 
<oauth@ietf.org<mailto:oauth@ietf.org>> <oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0

No, I'm not adding requirements for encryption. I was pointing out some of the 
ways that an access token might be different for different RSs.



On Mon, Apr 11, 2016 at 2:18 PM, Anthony Nadalin 
<tony...@microsoft.com<mailto:tony...@microsoft.com>> wrote:
So now you are adding more requirements for encryption ? The more this thread 
goes on shows how unstable and not fully thought out this draft is to go 
through WG adoption.

From: OAuth [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On 
Behalf Of Brian Campbell
Sent: Monday, April 11, 2016 12:30 PM
To: Nat Sakimura <sakim...@gmail.com<mailto:sakim...@gmail.com>>
Cc: <oauth@ietf.org<mailto:oauth@ietf.org>> 
<oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0

Sending a token type is not sufficient. There's more involved than the format. 
Many cases need to know if to encrypt and whom to encrypt to.  What claims to 
put in the token (or reference by the token). What algorithms and keys to use 
for signing/encryption.

The statement that the "Current proposal does not support the implicit flow" is 
incorrect. Among other things, sec 2 has, "When an access token will be 
returned from the authorization endpoint, the "resource" parameter is used in 
the authorization request to the authorization endpoint as defined in Section 
4.2.1 of OAuth 2.0 [RFC6749]."

On Sun, Apr 10, 2016 at 11:43 AM, Nat Sakimura 
<sakim...@gmail.com<mailto:sakim...@gmail.com>> wrote:
So, my understanding on the rationale/requirements for having this spec right 
now is:

R1. Authz server wants toprevent the replay by the server that received it.
R2. Authz server needs to mint the access token in a variety of format 
depending on the resource server and to do that, you need to know which RS is 
gong to be receiving it.

To achieve R1, there are couple of methods. The proposed method here is to 
audience restrict the token, but the same can be achieved by sender 
constraining the token, e.g., by token binding. As far as I can see, the 
sentiment of the WG seems to be to use the sender constraint through Token 
Binding, so from this respect, this spec is not the one to do R1. Besides, the 
current proposal only takes care of the code flow. The same requirement should 
be there for implicit flow as well, so the current proposal is not covering the 
R1 anyways.

I can sort of understand R2, but I have two critique on the current proposal:

C1. Current proposal does not support the implicit flow. To support it, the 
resource URI has to be sent to the Authz endpoint instead of the Token endpoint.
C2. It is much more direct to send the required token format rather than the RS 
uri and probably bet

Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0

[Anthony Nadalin]

So now you are adding more requirements for encryption ? The more this thread 
goes on shows how unstable and not fully thought out this draft is to go 
through WG adoption.

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Monday, April 11, 2016 12:30 PM
To: Nat Sakimura 
Cc:  
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0

Sending a token type is not sufficient. There's more involved than the format. 
Many cases need to know if to encrypt and whom to encrypt to.  What claims to 
put in the token (or reference by the token). What algorithms and keys to use 
for signing/encryption.

The statement that the "Current proposal does not support the implicit flow" is 
incorrect. Among other things, sec 2 has, "When an access token will be 
returned from the authorization endpoint, the "resource" parameter is used in 
the authorization request to the authorization endpoint as defined in Section 
4.2.1 of OAuth 2.0 [RFC6749]."

On Sun, Apr 10, 2016 at 11:43 AM, Nat Sakimura 
> wrote:
So, my understanding on the rationale/requirements for having this spec right 
now is:

R1. Authz server wants toprevent the replay by the server that received it.
R2. Authz server needs to mint the access token in a variety of format 
depending on the resource server and to do that, you need to know which RS is 
gong to be receiving it.

To achieve R1, there are couple of methods. The proposed method here is to 
audience restrict the token, but the same can be achieved by sender 
constraining the token, e.g., by token binding. As far as I can see, the 
sentiment of the WG seems to be to use the sender constraint through Token 
Binding, so from this respect, this spec is not the one to do R1. Besides, the 
current proposal only takes care of the code flow. The same requirement should 
be there for implicit flow as well, so the current proposal is not covering the 
R1 anyways.

I can sort of understand R2, but I have two critique on the current proposal:

C1. Current proposal does not support the implicit flow. To support it, the 
resource URI has to be sent to the Authz endpoint instead of the Token endpoint.
C2. It is much more direct to send the required token format rather than the RS 
uri and probably better as:
  1) There are use cases where the AS does not maintain the list of RSs that it 
supports, e.g., AOL.
   In such a case, even if the RS uri were sent to the AS, the AS cannot 
mint the tokens in the appropriate format.
  2) When it is sent in the Authz request, it is leaking the information about 
the resource that the client is going to the browser.
  3) There are use cases where it is desirable not to let the AS knows where 
the Client is going from the privacy point of view.

So, my suggestion is to drop R1 and concentrate on R2. And to solve R2, send 
token type instead of the resource indicator in the request.
This also necessitates the Client to be able to find out what token type the 
resource requires, perhaps in the unauthorized response web link header at the 
resource in the manner of oauth-meta.

Cheers,

Nat



2016年4月8日(金) 8:23 Prateek Mishra 
>:
While this work addresses a gap in the existing OAuth specification set, I am 
very concerned that this
incremental extension will lead to even more confusion around the areas of 
“scope”, “audience” and “resource server”.

I think we should try to solve this problem via  a framework that provides 
better guidance and implementation
models for OAuth use-cases. In other words, I feel that a broader discussion is 
needed here.


> On Apr 7, 2016, at 4:11 PM, Justin Richer 
> > wrote:
>
> I support adoption of this document as a starting point for working group 
> work.
>
> — Justin
>
>
>> On Apr 6, 2016, at 1:25 PM, Hannes Tschofenig 
>> > wrote:
>>
>> Hi all,
>>
>> this is the call for adoption of 'Resource Indicators for OAuth 2.0', see
>> http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/
>>
>> Please let us know by April 20th whether you accept / object to the
>> adoption of this document as a starting point for work in the OAuth
>> working group.
>>
>> Note: If you already stated your opinion at the IETF meeting in Buenos
>> Aires then you don't need to re-state your opinion, if you want.
>>
>> The feedback at the BA IETF meeting was the following: ~10 persons
>> for accepting the document and 0 persons against.
>>
>> Ciao
>> Hannes 

[OAUTH-WG] Token Binding and RFC5705

[Anthony Nadalin]

At the informal Token Binding meeting we had a discussion of Java servers 
supporting TB, the support would have to come out of JSSE, kere is the analysis 
on what it would take to change JSSE

Implementing 5705 itself, would not take too long and appears to be pretty 
straightforward.  The EKM is created by using the same PRF function as the 
creating of the key material from the TLS Master secret.
In TLS,

To generate the key material, compute



  key_block = PRF(SecurityParameters.master_secret,

  "key expansion",

  SecurityParameters.server_random +

  SecurityParameters.client_random);

For EKM,

If no context is provided, it then computes:



   PRF(SecurityParameters.master_secret, label,

   SecurityParameters.client_random +

   SecurityParameters.server_random

   )[length]



   If context is provided, it computes:



   PRF(SecurityParameters.master_secret, label,

   SecurityParameters.client_random +

   SecurityParameters.server_random +

   context_value_length + context_value

   )[length]

As it states in the RFC:  "The issue is the designing a secure mechanism that 
uses exporters is not necessarily straightforward. This document only provides 
the exporter mechanism, but the problem of agreeing on the surrounding context 
and the meaning of the information passed to and from the exporter remains. Any 
new uses of the exporter mechanism should be subject to careful review."

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

Re: [OAUTH-WG] OAuth 2.1

[Anthony Nadalin]

I don't belive that scopes should be defined more precisely as this opaqueness 
was a design feature, I'm not seeing the reason why scopes need to be defined, 
as these are application specific.

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt
Sent: Thursday, April 7, 2016 5:32 AM
To: George Fletcher 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.1

Hi all,

as I already said in the meeting: I would very much prefer to have an 
extension/update of RFC 6819 covering all "new" threats, including:
- mix up
- code injection aka copy and paste
- open redirector at AS and client
- potential other threats in the context of "dynamic" OAuth

I also assume mitigations for (at least some of) the threats need to go into an 
update of RFC 6749 as normative text. To give an example: if we agree on using 
the state parameter at the token endpoint to mitigate code injection, this MUST 
be part of the core spec (request description and security consoderations). 
Otherwise, noone will even  consider it.

We should also use the opportunity to improve/enhance the text of the spec. In 
the course of the last years, we have learned a lot about ambiquities of the 
text and how different implementations utilize OAuth. 

I think time is right to define scopes more precisely. As the discussions in 
the last days proved again (at least for me), scope is not sufficiently defined 
to come up with interoperable implementations. Additionally, there seems to be 
a need to represent resource server locations (to not say identities :-)) in 
this context.

To bundle all changes in a version 2.1 would also make communication into the 
market much easier. 

best regards,
Torsten.

> Am 06.04.2016 um 16:05 schrieb George Fletcher :
> 
> I'd definitely prefer a single solution document to many little ones that 
> have to be combined to actually build a secure solution. It's already getting 
> complex with the additional specs that have been added.
> 
> Additionally, I'm not against working on OAuth 2.1.
> 
> Thanks,
> George
> 
>> On 4/6/16 2:06 PM, Phil Hunt (IDM) wrote:
>>  
>> Existing implementations are for the large part ok and do not need these 
>> mitigations.
>> 
>> Only the new use cases we have been discussing (configure on the fly and 
>> multi-as, etc) really need mitigation.
>> 
>> The updated by approach seems like a good way to address the new cases.
>> 
>> Phil
>> 
>>> On Apr 6, 2016, at 14:35, Hannes Tschofenig  
>>> wrote:
>>> 
>>> Hi all,
>>> 
>>> today we discussed the OAuth Authorization Server Mixup draft. We 
>>> were wondering what types of threats the document should find solutions for.
>>> 
>>> We discussed various document handling approaches including
>>> * OAuth Mix-Up and Cut-and-Paste attacks documented in separate 
>>> solution documents
>>> * combined solution document covering the OAuth Mix-Up and the 
>>> Cut-and-Paste attacks.
>>> 
>>> Barry pointed out that these documents could update the OAuth base 
>>> specification.
>>> 
>>> As a more radical change it was also suggested to revise RFC 6749 
>>> "OAuth
>>> 2.0 Authorization Framework" and RFC 6819 "OAuth 2.0 Threat Model 
>>> and Security Considerations".
>>> 
>>> Opening up the OAuth base specification obviously raises various 
>>> other questions about cleaning up parts that go far beyond the AS 
>>> mix-up and the cut-and-paste attacks. Other specifications, such as 
>>> the Open Redirector, could be folded into such a new specification.
>>> 
>>> Derek and I would appreciate your input on this topic before we make 
>>> a decision since it has significant impact on our work.
>>> 
>>> Ciao
>>> Hannes & Derek
>>> 
>>> 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww
>>> .ietf.org%2fmailman%2flistinfo%2foauth=01%7c01%7ctonynad%40micr
>>> osoft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2
>>> d7cd011db47%7c1=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.
>> ietf.org%2fmailman%2flistinfo%2foauth=01%7c01%7ctonynad%40micros
>> oft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7c
>> d011db47%7c1=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.i
> etf.org%2fmailman%2flistinfo%2foauth=01%7c01%7ctonynad%40microsof
> t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd01
> 1db47%7c1=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d

___
OAuth mailing list
OAuth@ietf.org

Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0

[Anthony Nadalin]

I don’t see anything in the document that allows multiple resource servers 
where the token can be used. Token Exchange allows delegation and 
impersonation, so I have no idea of the semantics when I use both of these 
together

From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Wednesday, April 6, 2016 1:13 PM
To: Anthony Nadalin <tony...@microsoft.com>
Cc: Phil Hunt (IDM) <phil.h...@oracle.com>; oauth@ietf.org
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0

Multiple resources are there now.
I have no idea what "interaction with Token Exchange" means. Can you please 
explain?

On Wed, Apr 6, 2016 at 5:04 PM, Anthony Nadalin 
<tony...@microsoft.com<mailto:tony...@microsoft.com>> wrote:
I would like to see the multiple resources servers, interaction with Token 
Exchange resolved before this is adopted to see if this will actually solve the 
problems

From: OAuth [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On 
Behalf Of Brian Campbell
Sent: Wednesday, April 6, 2016 12:52 PM
To: Phil Hunt (IDM) <phil.h...@oracle.com<mailto:phil.h...@oracle.com>>
Cc: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0

I support the adoption of this draft by the working group.
I don't think an immediate WGLC was expected here.

On Wed, Apr 6, 2016 at 4:06 PM, Phil Hunt (IDM) 
<phil.h...@oracle.com<mailto:phil.h...@oracle.com>> wrote:
With the process of immediate wglc I think we should review all documents more 
thoroughly before adoption.

As I said I support the work.

Phil

> On Apr 6, 2016, at 16:02, Hannes Tschofenig 
> <hannes.tschofe...@gmx.net<mailto:hannes.tschofe...@gmx.net>> wrote:
>
> Phil,
>
> we have discussed this concept already for years. In fact, it dates back
> to the days of the OAuth base specification and the security
> consideration section even talks about it.
>
> We have had the content of this in the PoP key distribution draft and we
> are now moving it into a separate document.
>
> I am not sure how much longer you want to discuss it.
>
> Ciao
> Hannes
>
>
>> On 04/06/2016 08:07 PM, Phil Hunt (IDM) wrote:
>> I would like to have more discussion before wg adoption.
>>
>> I support the work and am willing to help.
>>
>> Phil
>>
>>> On Apr 6, 2016, at 14:25, Hannes Tschofenig 
>>> <hannes.tschofe...@gmx.net<mailto:hannes.tschofe...@gmx.net>> wrote:
>>>
>>> Hi all,
>>>
>>> this is the call for adoption of 'Resource Indicators for OAuth 2.0', see
>>> http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fdatatracker.ietf.org%2fdoc%2fdraft-campbell-oauth-resource-indicators%2f=01%7c01%7ctonynad%40microsoft.com%7c0db8d93df16c4462a54508d35e550020%7c72f988bf86f141af91ab2d7cd011db47%7c1=byM3LOXoRTVhgT8pECwr18fH8mpi69bReWGFiuOEbMA%3d>
>>>
>>> Please let us know by April 20th whether you accept / object to the
>>> adoption of this document as a starting point for work in the OAuth
>>> working group.
>>>
>>> Note: If you already stated your opinion at the IETF meeting in Buenos
>>> Aires then you don't need to re-state your opinion, if you want.
>>>
>>> The feedback at the BA IETF meeting was the following: ~10 persons
>>> for accepting the document and 0 persons against.
>>>
>>> Ciao
>>> Hannes & Derek
>>>
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org<mailto:OAuth@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth=01%7c01%7ctonynad%40microsoft.com%7c0db8d93df16c4462a54508d35e550020%7c72f988bf86f141af91ab2d7cd011db47%7c1=ITHT4xb2D%2bsq4auvEuOv1VUwqFl9lRON5aOL6oOst8U%3d>
>

___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth=01%7c01%7ctonynad%40microsoft.com%7c0db8d93df16c4462a54508d35e550020%7c72f988bf86f141af91ab2d7cd011db47%7c1=ITHT4xb2D%2bsq4auvEuOv1VUwqFl9lRON5aOL6oOst8U%3d>


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

Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0

[Anthony Nadalin]

I would like to see the multiple resources servers, interaction with Token 
Exchange resolved before this is adopted to see if this will actually solve the 
problems

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Wednesday, April 6, 2016 12:52 PM
To: Phil Hunt (IDM) 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0

I support the adoption of this draft by the working group.
I don't think an immediate WGLC was expected here.

On Wed, Apr 6, 2016 at 4:06 PM, Phil Hunt (IDM) 
> wrote:
With the process of immediate wglc I think we should review all documents more 
thoroughly before adoption.

As I said I support the work.

Phil

> On Apr 6, 2016, at 16:02, Hannes Tschofenig 
> > wrote:
>
> Phil,
>
> we have discussed this concept already for years. In fact, it dates back
> to the days of the OAuth base specification and the security
> consideration section even talks about it.
>
> We have had the content of this in the PoP key distribution draft and we
> are now moving it into a separate document.
>
> I am not sure how much longer you want to discuss it.
>
> Ciao
> Hannes
>
>
>> On 04/06/2016 08:07 PM, Phil Hunt (IDM) wrote:
>> I would like to have more discussion before wg adoption.
>>
>> I support the work and am willing to help.
>>
>> Phil
>>
>>> On Apr 6, 2016, at 14:25, Hannes Tschofenig 
>>> > wrote:
>>>
>>> Hi all,
>>>
>>> this is the call for adoption of 'Resource Indicators for OAuth 2.0', see
>>> http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/
>>>
>>> Please let us know by April 20th whether you accept / object to the
>>> adoption of this document as a starting point for work in the OAuth
>>> working group.
>>>
>>> Note: If you already stated your opinion at the IETF meeting in Buenos
>>> Aires then you don't need to re-state your opinion, if you want.
>>>
>>> The feedback at the BA IETF meeting was the following: ~10 persons
>>> for accepting the document and 0 persons against.
>>>
>>> Ciao
>>> Hannes & Derek
>>>
>>> ___
>>> 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] Informal Discussion about Discovery Today at 16:20

[Anthony Nadalin]

Wasn't this the task of the design team ?

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Wednesday, April 6, 2016 10:48 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Informal Discussion about Discovery Today at 16:20

Hi all,

during the f2f meeting today the suggestion was made to have another informal 
discussion about OAuth discovery.

We are going to meet at 16:20 today at the **IETF registration desk**.
William is trying to find a meeting room for us.

Please respond to me privately about this event, if you have feedback.

Ciao
Hannes

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

Re: [OAUTH-WG] [scim] Simple Federation Deployment server to server

[Anthony Nadalin]

Good question, since SCIM does not really provide an authorization model and 
Oauth does not do provisioning this is sort of caught in the middle, so if I 
had to pick I would pick Oauth as this is a generic server to server issue

From: Hardt, Dick [mailto:d...@amazon.com]
Sent: Wednesday, April 6, 2016 5:52 AM
To: Anthony Nadalin <tony...@microsoft.com>
Cc: Gil Kirkpatrick <gil.kirkpatr...@viewds.com>; Nat Sakimura 
<n-sakim...@nri.co.jp>; Phil Hunt (IDM) <phil.h...@oracle.com>; s...@ietf.org; 
oauth@ietf.org
Subject: Re: [scim] [OAUTH-WG] Simple Federation Deployment

Sounds like there is interest.

SCIM or OAUTH?

-- Dick

On Apr 6, 2016, at 8:57 AM, Anthony Nadalin 
<tony...@microsoft.com<mailto:tony...@microsoft.com>> wrote:
I would be interested also

Sent from my Windows 10 phone

From: Gil Kirkpatrick<mailto:gil.kirkpatr...@viewds.com>
Sent: Wednesday, April 6, 2016 4:16 AM
To: 'Nat Sakimura'<mailto:n-sakim...@nri.co.jp>; 'Hardt, 
Dick'<mailto:d...@amazon.com>; 'Phil Hunt (IDM)'<mailto:phil.h...@oracle.com>
Cc: s...@ietf.org<mailto:s...@ietf.org>; oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [scim] [OAUTH-WG] Simple Federation Deployment

That's an issue we're facing as well. Definitely interested.

-gil

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura
Sent: Wednesday, April 6, 2016 4:57 PM
To: 'Hardt, Dick' <d...@amazon.com<mailto:d...@amazon.com>>; 'Phil Hunt (IDM)' 
<phil.h...@oracle.com<mailto:phil.h...@oracle.com>>
Cc: s...@ietf.org<mailto:s...@ietf.org>; oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] [scim] Simple Federation Deployment

+1 for removing the manual cut-n-pastes!

Nat

--
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.

From: scim [mailto:scim-boun...@ietf.org] On Behalf Of Hardt, Dick
Sent: Wednesday, April 6, 2016 7:26 AM
To: Phil Hunt (IDM) <phil.h...@oracle.com<mailto:phil.h...@oracle.com>>
Cc: s...@ietf.org<mailto:s...@ietf.org>; oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [scim] Simple Federation Deployment

I'm talking about removing manual steps in what happens today where configuring 
a SaaS app at an IdP (such as Google, Azure, Ping, Octa) requires is a bunch of 
cutting and pasting of access tokens / keys / certs and doing a bunch of  
config that is error prone and unique for each relationship.

Don't want to solve on the thread ... looking to see if there is interest!

On 4/5/16, 7:11 PM, someone claiming to be "scim on behalf of Phil Hunt (IDM)" 
<scim-boun...@ietf.org<mailto:scim-boun...@ietf.org> on behalf of 
phil.h...@oracle.com<mailto:phil.h...@oracle.com>> wrote:

Is the idp the center of all things for these users?

Usually you have a provisioning system that coordinates state and uses things 
like scim connectors to do this.

Another approach from today would be to pass a scim event to the remote 
provider which then decides what needs to be done to facilitate the thingd you 
describe.

Iow. Either the idp (sender) or the sp (receiver) have a provisioning system to 
do this.

The solution and the simplicity depends on where the control needs to be.

Phil

On Apr 5, 2016, at 18:59, Hardt, Dick <d...@amazon.com<mailto:d...@amazon.com>> 
wrote:
Use case: An admin for an organization would like to enable her users to access 
a SaaS application at her IdP.

User experience:

  1.  Admin authenticates to IdP in browser
  2.  Admin selects SaaS app to federate with from list at IdP
  3.  IdP optionally presents config options
  4.  IdP redirects Admin to SaaS app
  5.  Admin authenticates to SaaS app
  6.  SaaS app optionally gathers config options
  7.  SaaS app redirects admin to IdP
  8.  IdP confirms successful federation => OIDC / SAML and SCIM are now 
configured and working between IdP and SaaS App
Who else is interested in solving this?

Is there interest in working on this in either SCIM or OAUTH Wgs?

Any one in BA interested in meeting on this topic this week?

- Dick
___
scim mailing list
s...@ietf.org<mailto:s...@ietf.org>
https://www.ietf.org/mailman/listinfo/scim<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fscim=01%7c01%7ctonynad%40microsoft.com%7c871da74138de485b0bb008d35deb6643%7c72f988bf86f141af91ab2d7cd011db47%7c1=%2fILmgXPgRyLfCIn%2b2EbpBbIcHqKJbKZVYKJBpUL%2fKnY%3d>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [scim] Simple Federation Deployment

[Anthony Nadalin]

I would be interested also

Sent from my Windows 10 phone

From: Gil Kirkpatrick
Sent: Wednesday, April 6, 2016 4:16 AM
To: 'Nat Sakimura'; 'Hardt, 
Dick'; 'Phil Hunt (IDM)'
Cc: s...@ietf.org; oauth@ietf.org
Subject: Re: [scim] [OAUTH-WG] Simple Federation Deployment

That's an issue we're facing as well. Definitely interested.

-gil

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura
Sent: Wednesday, April 6, 2016 4:57 PM
To: 'Hardt, Dick' ; 'Phil Hunt (IDM)' 
Cc: s...@ietf.org; oauth@ietf.org
Subject: Re: [OAUTH-WG] [scim] Simple Federation Deployment

+1 for removing the manual cut-n-pastes!

Nat

--
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.

From: scim [mailto:scim-boun...@ietf.org] On Behalf Of Hardt, Dick
Sent: Wednesday, April 6, 2016 7:26 AM
To: Phil Hunt (IDM) >
Cc: s...@ietf.org; oauth@ietf.org
Subject: Re: [scim] Simple Federation Deployment

I'm talking about removing manual steps in what happens today where configuring 
a SaaS app at an IdP (such as Google, Azure, Ping, Octa) requires is a bunch of 
cutting and pasting of access tokens / keys / certs and doing a bunch of  
config that is error prone and unique for each relationship.

Don't want to solve on the thread ... looking to see if there is interest!

On 4/5/16, 7:11 PM, someone claiming to be "scim on behalf of Phil Hunt (IDM)" 
 on behalf of 
phil.h...@oracle.com> wrote:

Is the idp the center of all things for these users?

Usually you have a provisioning system that coordinates state and uses things 
like scim connectors to do this.

Another approach from today would be to pass a scim event to the remote 
provider which then decides what needs to be done to facilitate the thingd you 
describe.

Iow. Either the idp (sender) or the sp (receiver) have a provisioning system to 
do this.

The solution and the simplicity depends on where the control needs to be.

Phil

On Apr 5, 2016, at 18:59, Hardt, Dick > 
wrote:
Use case: An admin for an organization would like to enable her users to access 
a SaaS application at her IdP.

User experience:

  1.  Admin authenticates to IdP in browser
  2.  Admin selects SaaS app to federate with from list at IdP
  3.  IdP optionally presents config options
  4.  IdP redirects Admin to SaaS app
  5.  Admin authenticates to SaaS app
  6.  SaaS app optionally gathers config options
  7.  SaaS app redirects admin to IdP
  8.  IdP confirms successful federation => OIDC / SAML and SCIM are now 
configured and working between IdP and SaaS App
Who else is interested in solving this?

Is there interest in working on this in either SCIM or OAUTH Wgs?

Any one in BA interested in meeting on this topic this week?

- Dick
___
scim mailing list
s...@ietf.org
https://www.ietf.org/mailman/listinfo/scim
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

[Anthony Nadalin]

Pushing documents such as AS metadata because Connect uses them does not help 
anything but muddies the water, Metadata is not a solution to Mix-up and 
Metadata is not a solution to Discovery, both Discovery and Mix-up are problems 
we need and agreed to fix. So I totally agree that we should not be conflating 
metadata with Mix-up or Discovery. I’m not hearing overwhelming consensus on 
adopting the metadata, maybe that is just consensus amongst OpenID folks and 
yes there are a few vocal people.

Most RS and AS relationships are not static relationships, we are seeing 
tenants that are suppling their own AS infrastructure as well as seeing 
portable RS’s which gets us into some very dynamic situations.



From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Tuesday, March 15, 2016 8:00 AM
To: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] New Version Notification for 
draft-hunt-oauth-bound-config-00.txt

Discovery in general for OAuth isn't well understood. This conversation and 
others like it around the 'discovery' draft demonstrate that. But publishing AS 
metadata is something that is understood and already in wide use for Connect. 
The rough consensus (except for a very few but vocal dissenters) on this list 
over the last few weeks/months has been that draft-ietf-oauth-discovery should 
describing AS metadata and its location. It's been suggested that the title 
reflect that scope and I might even suggest that the document identifier be 
changed to avoid further confusion.
The IDP mixup is addressed by the AS identifying itself to the client in the 
authorization response (it has a few other things in it that arguably shouldn't 
be in or should be elsewhere but that's a different question). The Mix-Up 
Mitigation draft uses the issuer value to do that. Issuer becomes a logical 
name/identifier for an AS. And that can tie it to AS metadata or even discovery 
if/when that exists. But discovery or AS metadata isn't necessary there. Yes 
Tony, we'd all like to see a comprehensive solution but conflating different 
and unrelated things is only making matters worse (as I'm sure you are well 
aware).
A 'bad RS' phishing for legitimate access tokens is a different kind of 
endpoint confusion. Most deployments now have a static relationship defined 
between RS and AS so it's more of a potential problem in the future. Despite 
the concern voiced about it the potential (as far as I can tell anyway), 
draft-hunt-oauth-bound-config provides a very nice attack vector for such a 
'bad RS' by pointing to an AS to obtain tokens it could misuse at legitimate 
RS(s). John has alluded to this.

There have been a number of incremental updates/extensions to OAuth 2.0 and 
there look to be more coming.  Concerns have been expressed over the number of 
documents and implements knowing what to use when. I don't think the answer is 
to try and jam unrelated new stuff into new docs to keep the number of docs low 
is a good idea though. I'd much prefer to have concise and cohesive documents. 
The larger issue of confusion around too many documents should be addressed at 
a higher level. For example, something like an implementation guide or even 
something like an OAuth 2.1 that describes the available extensions and 
when/why one would use them.



On Mon, Mar 14, 2016 at 4:29 PM, Anthony Nadalin 
<tony...@microsoft.com<mailto:tony...@microsoft.com>> wrote:
I would really like to see a comprehensive solution not this piece work, so we 
know what we are solving and what we are not.

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On 
Behalf Of Hans Zandbelt
Sent: Monday, March 14, 2016 3:26 PM
To: Phil Hunt (IDM) <phil.h...@oracle.com<mailto:phil.h...@oracle.com>>; John 
Bradley <ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>>
Cc: oauth <oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] New Version Notification for 
draft-hunt-oauth-bound-config-00.txt

On 3/14/16 10:17 PM, Phil Hunt (IDM) wrote:

> On Mar 14, 2016, at 14:13, John Bradley 
> <ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>
> <mailto:ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>>> wrote:
>> Any client that has the resource and issuer hard coded probably
>> doesn't need discovery.
> We agree

Yet any client that has hard coded a resource and 2 issuers doesn't need 
discovery either but is vulnerable to the IDP mixup attack.

I'd really like to see the two being addressed independently of each other, 
regardless of the fact that a Discovery solution *could* solve the IDP mixup 
attack as well.

Hans.

--
Hans Zandbelt  | Sr. Technical Architect
hzandb...@pingidentity.com<mailto:hzandb...@pingidentity.com> | Ping Identity

___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://na01.safelin

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

[Anthony Nadalin]

I would really like to see a comprehensive solution not this piece work, so we 
know what we are solving and what we are not.

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hans Zandbelt
Sent: Monday, March 14, 2016 3:26 PM
To: Phil Hunt (IDM) ; John Bradley 
Cc: oauth 
Subject: Re: [OAUTH-WG] New Version Notification for 
draft-hunt-oauth-bound-config-00.txt

On 3/14/16 10:17 PM, Phil Hunt (IDM) wrote:

> On Mar 14, 2016, at 14:13, John Bradley  > wrote:
>> Any client that has the resource and issuer hard coded probably 
>> doesn't need discovery.
> We agree

Yet any client that has hard coded a resource and 2 issuers doesn't need 
discovery either but is vulnerable to the IDP mixup attack.

I'd really like to see the two being addressed independently of each other, 
regardless of the fact that a Discovery solution *could* solve the IDP mixup 
attack as well.

Hans.

-- 
Hans Zandbelt  | Sr. Technical Architect
hzandb...@pingidentity.com | Ping Identity

___
OAuth mailing list
OAuth@ietf.org
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth=01%7c01%7ctonynad%40microsoft.com%7c8cd9a8b2e020444382a708d34c57a6b4%7c72f988bf86f141af91ab2d7cd011db47%7c1=1dsstJfhduQ3mZERUx6%2fO3OE241RK7ataalg6RY6JmA%3d

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

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

[Anthony Nadalin]

fault 
oauth-server one.

That then allows us to deal with restricting where AT are presented as part of 
the protocol rather then dragging discovery in as a requirement.

In my opinion the resource the token is targeted to should be separated from 
the scope and returned as part of the meta-data about the AT along with scopes 
granted and expiry time.   We should also have a input parameter for resources 
so that a client can restrict tokens issued to a subset of the ones granted by 
the refresh token.   It would then also be possible to ask a AS for a token for 
a unregistered RS and have the AS produce a JWT access token with the resource 
as an audience if policy allows.

That however was supposed to be dealt with as part of the mixed up client set 
of mitigations.
In that the goal was to mitigate the attacks by returning meta-data about the 
tokens, and not to require discovery.

We intend to return “iss” and “cleint_id” for the code, and I intend to discuss 
at the F2F returning resource for AT as well.

Those mitigate the attack.

I will continue to resist mixing up discovery of configuration meta-data with 
mitigation of the attacks.

We return meta-data about the tokens now, because AT are opaque to the client, 
we neglected to include some of the information for the client needs to be 
secure.   We just need to add that in to the existing flows.

While Phil’s proposal is easier for the AS to implement as an add on, it puts 
more of a burden on the client needing to potentially change how it stores the 
relationships between AS and RS to prevent compromise, I think the solution 
should be biased towards simplicity on the client side.

If we return the resources as part of the existing meta data the client checks 
that against the resource it intends to send the token to and if it is not in 
the list then it can’t send the token.  Simple check every time it gets a new 
AT, no optionality.

I am not saying anything new Nat has been advocating basically this for some 
time, and dis submit a draft.   I prefer to return the info in the existing 
format rather than as link headers,  but that is the largest difference between 
what Nat and I are saying with respect to resource.

That is the core of my problem with Phil’s draft.

I guess we will need to have a long conversation in BA.

Regards
John B.

On Mar 13, 2016, at 8:12 PM, Phil Hunt 
<phil.h...@oracle.com<mailto:phil.h...@oracle.com>> wrote:

This draft is a proposed alternate proposal for draft-ietf-oauth-discovery.  As 
such, it contains the same registry for OAuth Config Metadata as the authors 
believe that both solutions are not required, or depending on WG discussion 
they will be merged. The intent is to provide a simple complete draft for 
consideration.

How it works...
Given that a client has previously discovered an OAuth protected resource, the 
bound configuration method allows a client to return the configuration for an 
oauth authorization server that can issue tokens for the resource URI specified 
by the client.  The AS is not required to be in the same domain.  The AS is 
however required to know if it can issue tokens for a resource service (which 
presumes some agreement exists on tokens etc).

The draft does not require that the resource exist (e.g. for unconfigured or 
new user based resources). It only requires that the AS service provider agrees 
it can issue tokens.

From a security perspective, returning the OAuth service configuration for a 
specified resource URI serves to confirm the client is in possession of a valid 
resource URI ensuring the client has received a valid set of endpoints for the 
resource and the associated oauth services.

I propose that the WG consider the alternate draft carefully as well as other 
submissions and evaluate the broader discovery problem before proceeding with 
WGLC on OAuth Discovery.

Thanks!

Phil

@independentid
www.independentid.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.independentid.com%2f=01%7c01%7ctonynad%40microsoft.com%7c58284b200e8f43930bf708d34bc98ca0%7c72f988bf86f141af91ab2d7cd011db47%7c1=wYX1bvmaiwFUTnQfR4mcHcmzYtNA9K19vVwgPX%2fFki4%3d>
phil.h...@oracle.com<mailto:phil.h...@oracle.com>


Begin forwarded message:

From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>
Subject: New Version Notification for draft-hunt-oauth-bound-config-00.txt
Date: March 13, 2016 at 3:53:37 PM PDT
To: "Phil Hunt" <phil.h...@yahoo.com<mailto:phil.h...@yahoo.com>>, "Anthony 
Nadalin" <tony...@microsoft.com<mailto:tony...@microsoft.com>>, "Tony Nadalin" 
<tony...@microsoft.com<mailto:tony...@microsoft.com>>


A new version of I-D, draft-hunt-oauth-bound-config-00.txt
has been successfully submitted by Phil Hunt and posted to the
IETF repository.

Name: draft-hunt-oauth-bound-config
Revision: 00
Title:   OAuth 2.0 Bound Conf

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

[Anthony Nadalin]

This is not discovery, its simply metadata, it’s unclear if this is all the 
metadata that is needed  because discovery has not been fully thought out as 
apparent from all the exchanges that have been going on, I don’t understand the 
rush to get this document out when we already know it’s incomplete

There are still documents from Nat, and I believe there will be one from Phil 
and maybe others.

From: Mike Jones
Sent: Saturday, March 12, 2016 8:29 AM
To: Anthony Nadalin <tony...@microsoft.com>; Brian Campbell 
<bcampb...@pingidentity.com>; John Bradley <ve7...@ve7jtb.com>
Cc: oauth <oauth@ietf.org>
Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

The AS metadata format is a necessary part of discovery.  No, it doesn’t 
accomplish every possible aspect of discovery – nor was it ever intended to.  
I’ve consistently encouraged Phil and others to write down additional aspects 
of discovery in specifications that build upon this one so that the working 
group and implementers can evaluate them.

Since we’re chartered to do discovery and this is part of discovery, no 
rechartering is needed either for the current specification or for new 
specifications performing additional discovery tasks.

  -- Mike

From: Anthony Nadalin
Sent: Saturday, March 12, 2016 8:20 AM
To: Mike Jones 
<michael.jo...@microsoft.com<mailto:michael.jo...@microsoft.com>>; Brian 
Campbell <bcampb...@pingidentity.com<mailto:bcampb...@pingidentity.com>>; John 
Bradley <ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>>
Cc: oauth <oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

We agreed upon a discovery specification that the WG would work on, we did not 
agree upon what this has turned out to actually be, so at the minimum the 
chairs should call for adoption of a Authorization Server Metadata 
specification and we can continue to work on a Discovery specification

From: Mike Jones
Sent: Saturday, March 12, 2016 8:06 AM
To: Anthony Nadalin <tony...@microsoft.com<mailto:tony...@microsoft.com>>; 
Brian Campbell <bcampb...@pingidentity.com<mailto:bcampb...@pingidentity.com>>; 
John Bradley <ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>>
Cc: oauth <oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

The draft enables easy configuration of OAuth clients with an AS.  For 
instance, the Microsoft “ADAL” OAuth client software uses AS metadata in this 
format as an input at client configuration time.

As a side benefit, having this standard AS metadata format and returning the 
issuer URL per the Mix-Up Mitigation draft will also enable clients to validate 
that they are using a consistent set of AS endpoints and information.  But even 
without the mitigation benefits, the client configuration benefit is the 
primary reason for the specification.

      -- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
Sent: Friday, March 11, 2016 3:25 PM
To: Brian Campbell 
<bcampb...@pingidentity.com<mailto:bcampb...@pingidentity.com>>; John Bradley 
<ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>>
Cc: oauth <oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

Disagree, what purpose is this activity solving then, it was being pushed as 
what was need to solve the Mix-up, but that is not true. So now you are 
suggesting a change in scope and not dealing with discovery.

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Friday, March 11, 2016 3:11 PM
To: John Bradley <ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>>
Cc: oauth <oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

I tend to agree with John that addressing the concerns Phil raises should be 
part of (extension to) the core protocol.  And that those kinds of concerns 
don't manifest in the way OAuth is typically deployed now.

The hopefully soon to be named "OAuth 2.0 Authorization Server Metadata" should 
keep it's scope to the publishing of authorization server metadata. The act of 
doing discovery is beyond its scope and so is trying to prevent a client from 
presenting a token to someplace it shouldn't.

On Fri, Mar 11, 2016 at 9:08 AM, John Bradley 
<ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>> wrote:
Inline
On Mar 11, 2016, at 12:13 PM, Phil Hunt (IDM) 
<phil.h...@oracle.com<mailto:phil.h...@oracle.com>> wrote:

John

In many case all the AS has to check is the domain name component to check for 
mitm.

POP and the other solns are dramatically more complex than a simple ch

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

[Anthony Nadalin]

We agreed upon a discovery specification that the WG would work on, we did not 
agree upon what this has turned out to actually be, so at the minimum the 
chairs should call for adoption of a Authorization Server Metadata 
specification and we can continue to work on a Discovery specification

From: Mike Jones
Sent: Saturday, March 12, 2016 8:06 AM
To: Anthony Nadalin <tony...@microsoft.com>; Brian Campbell 
<bcampb...@pingidentity.com>; John Bradley <ve7...@ve7jtb.com>
Cc: oauth <oauth@ietf.org>
Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

The draft enables easy configuration of OAuth clients with an AS.  For 
instance, the Microsoft “ADAL” OAuth client software uses AS metadata in this 
format as an input at client configuration time.

As a side benefit, having this standard AS metadata format and returning the 
issuer URL per the Mix-Up Mitigation draft will also enable clients to validate 
that they are using a consistent set of AS endpoints and information.  But even 
without the mitigation benefits, the client configuration benefit is the 
primary reason for the specification.

  -- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
Sent: Friday, March 11, 2016 3:25 PM
To: Brian Campbell 
<bcampb...@pingidentity.com<mailto:bcampb...@pingidentity.com>>; John Bradley 
<ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>>
Cc: oauth <oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

Disagree, what purpose is this activity solving then, it was being pushed as 
what was need to solve the Mix-up, but that is not true. So now you are 
suggesting a change in scope and not dealing with discovery.

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Friday, March 11, 2016 3:11 PM
To: John Bradley <ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>>
Cc: oauth <oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

I tend to agree with John that addressing the concerns Phil raises should be 
part of (extension to) the core protocol.  And that those kinds of concerns 
don't manifest in the way OAuth is typically deployed now.

The hopefully soon to be named "OAuth 2.0 Authorization Server Metadata" should 
keep it's scope to the publishing of authorization server metadata. The act of 
doing discovery is beyond its scope and so is trying to prevent a client from 
presenting a token to someplace it shouldn't.

On Fri, Mar 11, 2016 at 9:08 AM, John Bradley 
<ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>> wrote:
Inline
On Mar 11, 2016, at 12:13 PM, Phil Hunt (IDM) 
<phil.h...@oracle.com<mailto:phil.h...@oracle.com>> wrote:

John

In many case all the AS has to check is the domain name component to check for 
mitm.

POP and the other solns are dramatically more complex than a simple check.

I was proposing ding that check at the authorization endpoint or token endpoint 
as part of AT issuance.

It is up to the AS how much of the path to validate and or put in the aud or 
dst.



I see it as part of the discovery(bad name aside) problem because we discussed 
that if a client finds 
app.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fapp.example.com%2f=01%7c01%7ctonynad%40microsoft.com%7c4b9bae5dda7a45096b8408d34a031e57%7c72f988bf86f141af91ab2d7cd011db47%7c1=fiS8f60ypiXhyM0qVTeql%2b%2bOzH2wbmECQE7J5TtGPQM%3d>
 how do we ensure it gets a complete set of oauth endpoints as a valid set of 
endpoints--that a hacker has not inserted one of their own endpoints. The most 
important endpoint to get right is ensuring the resource server (and optionally 
the path) is the correct one. We can't really define resource discovery but we 
can validate it to some degree.

I think it is part of core protocol security and should/must not require 
discovery.

What is 
app.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fapp.example.com=01%7c01%7ctonynad%40microsoft.com%7c4b9bae5dda7a45096b8408d34a031e57%7c72f988bf86f141af91ab2d7cd011db47%7c1=jAsZQeChJ%2bR1lbyBoVKwheIYi3PiWLrq%2bxDLbqU6rxk%3d>
 ?

If it is the resource then the client would be preconfigured for it’s AS out of 
band or optionally would do discovery on the issuer uri that you admit needs to 
be configured out of band some way (note discovery is optional)

In the AS meta-data draft it would do a get on a well known file that would 
have configuration for the AS, but not the RS, though some API may optionally 
list a API endpoint like connect has.

The client then makes a authorization request (after registering out of band or 
dynamically).
As part of the authorization request for implicit it could provide the aud/dst 
that it wants the token for.
If that 

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

[Anthony Nadalin]

Sorry but not true, this started out as “discovery” and now it’s not

From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Friday, March 11, 2016 3:59 PM
To: Anthony Nadalin <tony...@microsoft.com>
Cc: John Bradley <ve7...@ve7jtb.com>; oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

That *is* the scope of the current document, which a majority of folks have 
agreed with. I was reiterating that the name of the document should reflect its 
content, something else that has been widely agreed with.

On Fri, Mar 11, 2016 at 4:24 PM, Anthony Nadalin 
<tony...@microsoft.com<mailto:tony...@microsoft.com>> wrote:
Disagree, what purpose is this activity solving then, it was being pushed as 
what was need to solve the Mix-up, but that is not true. So now you are 
suggesting a change in scope and not dealing with discovery.

From: OAuth [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On 
Behalf Of Brian Campbell
Sent: Friday, March 11, 2016 3:11 PM
To: John Bradley <ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>>

Cc: oauth <oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

I tend to agree with John that addressing the concerns Phil raises should be 
part of (extension to) the core protocol.  And that those kinds of concerns 
don't manifest in the way OAuth is typically deployed now.

The hopefully soon to be named "OAuth 2.0 Authorization Server Metadata" should 
keep it's scope to the publishing of authorization server metadata. The act of 
doing discovery is beyond its scope and so is trying to prevent a client from 
presenting a token to someplace it shouldn't.

On Fri, Mar 11, 2016 at 9:08 AM, John Bradley 
<ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>> wrote:
Inline
On Mar 11, 2016, at 12:13 PM, Phil Hunt (IDM) 
<phil.h...@oracle.com<mailto:phil.h...@oracle.com>> wrote:

John

In many case all the AS has to check is the domain name component to check for 
mitm.

POP and the other solns are dramatically more complex than a simple check.

I was proposing ding that check at the authorization endpoint or token endpoint 
as part of AT issuance.

It is up to the AS how much of the path to validate and or put in the aud or 
dst.



I see it as part of the discovery(bad name aside) problem because we discussed 
that if a client finds 
app.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fapp.example.com%2f=01%7c01%7ctonynad%40microsoft.com%7c4b9bae5dda7a45096b8408d34a031e57%7c72f988bf86f141af91ab2d7cd011db47%7c1=fiS8f60ypiXhyM0qVTeql%2b%2bOzH2wbmECQE7J5TtGPQM%3d>
 how do we ensure it gets a complete set of oauth endpoints as a valid set of 
endpoints--that a hacker has not inserted one of their own endpoints. The most 
important endpoint to get right is ensuring the resource server (and optionally 
the path) is the correct one. We can't really define resource discovery but we 
can validate it to some degree.

I think it is part of core protocol security and should/must not require 
discovery.

What is 
app.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fapp.example.com=01%7c01%7ctonynad%40microsoft.com%7c4b9bae5dda7a45096b8408d34a031e57%7c72f988bf86f141af91ab2d7cd011db47%7c1=jAsZQeChJ%2bR1lbyBoVKwheIYi3PiWLrq%2bxDLbqU6rxk%3d>
 ?

If it is the resource then the client would be preconfigured for it’s AS out of 
band or optionally would do discovery on the issuer uri that you admit needs to 
be configured out of band some way (note discovery is optional)

In the AS meta-data draft it would do a get on a well known file that would 
have configuration for the AS, but not the RS, though some API may optionally 
list a API endpoint like connect has.

The client then makes a authorization request (after registering out of band or 
dynamically).
As part of the authorization request for implicit it could provide the aud/dst 
that it wants the token for.
If that is not sent then the aud/dst are implicit in the scopes.

The client gets back a AT with a list of scopes granted, aud/dst allowed and 
time to live for the token (one extra thing returned)

This doesn’t require any discovery (yes there is a optional AS meta-data 
discovery but not required)

I prefer to fix the RS man in the middle issue as part of the protocol and not 
part of discovery that should remain optional.

I honestly don’t quite know how the client learns about this bad RS and starts 
talking to it, so this may be a solution to a problem that doesn’t yet exist.   
The one place this is posable is if the registration for the client is 
compromised.  However we are discussing other mitigations for that that also 
explicitly do not require discovery.

John B.


I am not stuck on webfinger or well-known. Because this is config maybe it 
should be an oauth endpoint.

Phil

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

[Anthony Nadalin]

th dst and scope in the response all along, so this is 
update that is consistent with the eisting architecture of OAuth 2.

Lets keep the two issues separate.

John B.




On Mar 11, 2016, at 12:07 AM, Anthony Nadalin 
<tony...@microsoft.com<mailto:tony...@microsoft.com>> wrote:

The relationship between AS and RS need to be scoped to “does this RS accept 
tokens from this AS” as a list is too much information that could be used in 
the wrong way

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura
Sent: Thursday, March 10, 2016 6:25 PM
To: Phil Hunt (IDM) <phil.h...@oracle.com<mailto:phil.h...@oracle.com>>
Cc: oauth <oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

Phil,

Right. So what my conditional approvals (11 conditions in total) said was to 
drop the word "discovery" from everywhere. This is not a discovery spec. This 
is a configuration lookup spec as you correctly points out. So, I am with you 
here.

Also, my 2nd conditiion is essentially saying to drop section 3.

One thing that I overlooked and am with you is that we need to be able to 
express the AS-RS relationships. I have been preaching this in the other thread 
for so many times as you know so I thought I pointed it out, but missed 
apparently in my previous comment. So, I would add my 12th condition:

12. A way to express a list of valid RSs for this AS needs to be added to 
section 2.

Best,

Nat

2016-03-11 2:09 GMT+09:00 Phil Hunt (IDM) 
<phil.h...@oracle.com<mailto:phil.h...@oracle.com>>:
I strongly oppose. 2 major issues.

This is not service discovery this is configuration lookup. The client must 
have already discovered the oauth issuer uri and the resource uri.

The objective was to provide a method to ensure the client has a valid set of 
endpoints to prevent mitm of endpoints like the token endpoint to the resource 
server.

The draft does not address the issue of a client being given a bad endpoint for 
an rs. What we end up with is a promiscuous authz service giving out tokens to 
an unwitting client.

Phil

On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov 
<vladi...@connect2id.com<mailto:vladi...@connect2id.com>> wrote:
+1 to move forward with these
On 10/03/16 17:35, Brian Campbell wrote:

+1



On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg 
<roland.hedb...@umu.se><mailto:roland.hedb...@umu.se>

wrote:



I support this document being moved forward with these two changes:



- change name to “OAuth 2.0 Authorization Server Discovery Metadata” as

proposed by Brian and

- use the URI path suffix ’oauth-authorization-server’ instead of

’openid-configuration’ as proposed by Justin.



18 feb 2016 kl. 14:40 skrev Hannes Tschofenig 
<hannes.tschofe...@gmx.net<mailto:hannes.tschofe...@gmx.net>

:



Hi all,



This is a Last Call for comments on the  OAuth 2.0 Discovery

specification:

https://tools.ietf.org/html/draft-ietf-oauth-discovery-01<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-discovery-01=01%7c01%7ctonynad%40microsoft.com%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1=w3%2biiaWon81LJCU%2b2mCPRmA%2brECBHgqyRr0OgqiWSHU%3d>



Since this document was only adopted recently we are running this last

call for **3 weeks**.



Please have your comments in no later than March 10th.



Ciao

Hannes & Derek



___

OAuth mailing list

OAuth@ietf.org<mailto:OAuth@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth=01%7c01%7ctonynad%40microsoft.com%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1=tNCikmXDBF7ubk%2b%2bzJiXwPB0LIzQXA%2fk%2bqR9m5WgA2k%3d>

— Roland



”Everybody should be quiet near a little stream and listen."

>From ’Open House for Butterflies’ by Ruth Krauss





___

OAuth mailing list

OAuth@ietf.org<mailto:OAuth@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth=01%7c01%7ctonynad%40microsoft.com%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1=tNCikmXDBF7ubk%2b%2bzJiXwPB0LIzQXA%2fk%2bqR9m5WgA2k%3d>






___

OAuth mailing list

OAuth@ietf.org<mailto:OAuth@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth=01%7c01%7ctonynad%40microsoft.com%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1=tNCikmXDBF7ubk%2b%2bzJiXwPB0LIzQXA%2fk%2bqR9m5WgA2k%3d>

_

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

[Anthony Nadalin]

There have been way too many issues, confused conversations and discussions on 
and off list to have this document move forward, suggest that this be one of 
the main items on the agenda for when we meet.

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt (IDM)
Sent: Thursday, March 10, 2016 9:09 AM
To: Vladimir Dzhuvinov 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

I strongly oppose. 2 major issues.

This is not service discovery this is configuration lookup. The client must 
have already discovered the oauth issuer uri and the resource uri.

The objective was to provide a method to ensure the client has a valid set of 
endpoints to prevent mitm of endpoints like the token endpoint to the resource 
server.

The draft does not address the issue of a client being given a bad endpoint for 
an rs. What we end up with is a promiscuous authz service giving out tokens to 
an unwitting client.

Phil

On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov 
> wrote:
+1 to move forward with these
On 10/03/16 17:35, Brian Campbell wrote:

+1



On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg 


wrote:



I support this document being moved forward with these two changes:



- change name to “OAuth 2.0 Authorization Server Discovery Metadata” as

proposed by Brian and

- use the URI path suffix ’oauth-authorization-server’ instead of

’openid-configuration’ as proposed by Justin.



18 feb 2016 kl. 14:40 skrev Hannes Tschofenig 


:



Hi all,



This is a Last Call for comments on the  OAuth 2.0 Discovery

specification:

https://tools.ietf.org/html/draft-ietf-oauth-discovery-01



Since this document was only adopted recently we are running this last

call for **3 weeks**.



Please have your comments in no later than March 10th.



Ciao

Hannes & Derek



___

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth

— Roland



”Everybody should be quiet near a little stream and listen."

From ’Open House for Butterflies’ by Ruth Krauss





___

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] Working Group Last Call on OAuth 2.0 Discovery

[Anthony Nadalin]

The relationship between AS and RS need to be scoped to “does this RS accept 
tokens from this AS” as a list is too much information that could be used in 
the wrong way

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura
Sent: Thursday, March 10, 2016 6:25 PM
To: Phil Hunt (IDM) 
Cc: oauth 
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

Phil,

Right. So what my conditional approvals (11 conditions in total) said was to 
drop the word "discovery" from everywhere. This is not a discovery spec. This 
is a configuration lookup spec as you correctly points out. So, I am with you 
here.

Also, my 2nd conditiion is essentially saying to drop section 3.

One thing that I overlooked and am with you is that we need to be able to 
express the AS-RS relationships. I have been preaching this in the other thread 
for so many times as you know so I thought I pointed it out, but missed 
apparently in my previous comment. So, I would add my 12th condition:

12. A way to express a list of valid RSs for this AS needs to be added to 
section 2.

Best,

Nat

2016-03-11 2:09 GMT+09:00 Phil Hunt (IDM) 
>:
I strongly oppose. 2 major issues.

This is not service discovery this is configuration lookup. The client must 
have already discovered the oauth issuer uri and the resource uri.

The objective was to provide a method to ensure the client has a valid set of 
endpoints to prevent mitm of endpoints like the token endpoint to the resource 
server.

The draft does not address the issue of a client being given a bad endpoint for 
an rs. What we end up with is a promiscuous authz service giving out tokens to 
an unwitting client.

Phil

On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov 
> wrote:
+1 to move forward with these
On 10/03/16 17:35, Brian Campbell wrote:

+1



On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg 


wrote:



I support this document being moved forward with these two changes:



- change name to “OAuth 2.0 Authorization Server Discovery Metadata” as

proposed by Brian and

- use the URI path suffix ’oauth-authorization-server’ instead of

’openid-configuration’ as proposed by Justin.



18 feb 2016 kl. 14:40 skrev Hannes Tschofenig 


:



Hi all,



This is a Last Call for comments on the  OAuth 2.0 Discovery

specification:

https://tools.ietf.org/html/draft-ietf-oauth-discovery-01



Since this document was only adopted recently we are running this last

call for **3 weeks**.



Please have your comments in no later than March 10th.



Ciao

Hannes & Derek



___

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth

— Roland



”Everybody should be quiet near a little stream and listen."

>From ’Open House for Butterflies’ by Ruth Krauss





___

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



--
Nat Sakimura (=nat)
Chairman, OpenID Foundation

Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-meta-07.txt

[Anthony Nadalin]

So as I understand it in the Link Relations repository are XML documents that 
one has to create, are you suggesting as part of this effort is to rewrite all 
that in JSON and make a proposal for that also ?

From: Nat Sakimura [mailto:sakim...@gmail.com]
Sent: Tuesday, February 16, 2016 4:55 PM
To: Anthony Nadalin <tony...@microsoft.com>; oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for 
draft-sakimura-oauth-meta-07.txt

Link relation is not at all XML. It is a step forward to RESTfulness.
In the older version of the draft, I was using JSONized version of it as well, 
but I splitted it out for the sake of brevity.
It is all about dynamic metadata about the response.
Once we do it with RFC5988, we could easily create a parallel to it with JSON 
meta object of your flavour.
(Currently, JSON schema seems to be in fashion, though I personally prefer HAL.)
Good things about using JSONized version is that it will be usable outside the 
HTTP and the fact that it can be stored in a single JSON object together with 
the data.
Bad thing about it is that we have to start from the syntax for it, which we 
can avoid by using RFC5988.
If people want the JSON version of this, I could do it as well.
However, since we are processing HTTP response headers anyways, there is not 
much compelling reason for that as long as we stick with HTTP.
That's why I am just sticking with RFC5988.

Nat.


2016年2月17日(水) 8:50 Anthony Nadalin 
<tony...@microsoft.com<mailto:tony...@microsoft.com>>:
I really think that this is a step backwards relative to technology and what 
the developers would accept. The Link Relations takes us back to the XML days, 
I thought we have all moved on from that and at least trying to move Oauth to 
JSON. I think if this were adopted we might be splitting the developers into 
folks that are already going down the current JSON path with Oauth and those 
that want to go back to XML.

This just seems a very odd draft to adopt this technology.

From: OAuth [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On 
Behalf Of Nat Sakimura
Sent: Monday, February 15, 2016 3:59 PM
To: oauth <oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: [OAUTH-WG] Fwd: New Version Notification for 
draft-sakimura-oauth-meta-07.txt

It now shows how to return multiple endpoints in web linking.
Also, added Resource Endpoint response header.

Best,

nat

-- Forwarded message -
From: <internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>>
Date: 2016年2月12日(金) 18:40
Subject: New Version Notification for draft-sakimura-oauth-meta-07.txt
To: Nov Matake <n...@matake.jp<mailto:n...@matake.jp>>, Nat Sakimura 
<sakim...@gmail.com<mailto:sakim...@gmail.com>>, Sascha Preibisch 
<sascha.preibi...@gmail.com<mailto:sascha.preibi...@gmail.com>>, Sascha 
Preibisch <sascha.preibi...@gmail.com<mailto:sascha.preibi...@gmail.com>>



A new version of I-D, draft-sakimura-oauth-meta-07.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Name:   draft-sakimura-oauth-meta
Revision:   07
Title:  OAuth Response Metadata
Document date:  2016-02-12
Group:  Individual Submission
Pages:  10
URL:
https://www.ietf.org/internet-drafts/draft-sakimura-oauth-meta-07.txt<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2finternet-drafts%2fdraft-sakimura-oauth-meta-07.txt=01%7c01%7ctonynad%40microsoft.com%7c3a992d5ff4a2428804f208d336641292%7c72f988bf86f141af91ab2d7cd011db47%7c1=6M10Q9X4cq%2b%2fRroR%2fHYQ9IN3P1HO06JnbuzY6P3oWtc%3d>
Status: 
https://datatracker.ietf.org/doc/draft-sakimura-oauth-meta/<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fdatatracker.ietf.org%2fdoc%2fdraft-sakimura-oauth-meta%2f=01%7c01%7ctonynad%40microsoft.com%7c3a992d5ff4a2428804f208d336641292%7c72f988bf86f141af91ab2d7cd011db47%7c1=7twEM0FztSaswtFiYslvJuadTyWbWRSDWQ6uT%2bevKwM%3d>
Htmlized:   
https://tools.ietf.org/html/draft-sakimura-oauth-meta-07<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-sakimura-oauth-meta-07=01%7c01%7ctonynad%40microsoft.com%7c3a992d5ff4a2428804f208d336641292%7c72f988bf86f141af91ab2d7cd011db47%7c1=kh2nH4IyNm3OAA5nkrSFzZN16Xic%2b2EDUOfr%2fG6CjVY%3d>
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-meta-07<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2frfcdiff%3furl2%3ddraft-sakimura-oauth-meta-07=01%7c01%7ctonynad%40microsoft.com%7c3a992d5ff4a2428804f208d336641292%7c72f988bf86f141af91ab2d7cd011db47%7c1=ICtk5U1e6kBPFI8ov0n06TAcqDX3HurgFTydXKD73Yo%3d>

Abstract:
   This specification defines an extensible metadata that may be
   inserted into the OAuth 2.0 responses to assist the clients to
   process those responses.  It is expressed either as a li

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Anthony Nadalin]

Sure there is, it is as you have now made it far easier and the security 
considerations does not even address this

From: Mike Jones
Sent: Wednesday, February 24, 2016 10:22 AM
To: Anthony Nadalin <tony...@microsoft.com>
Cc: <oauth@ietf.org> <oauth@ietf.org>
Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location

As we’d discussed in person, there’s no effective security difference between 
discovery information being published in an ad-hoc fashion on developer pages 
and it being published in a standard format.  “Security by obscurity” adds no 
real security at all.

  -- Mike

From: Anthony Nadalin
Sent: Wednesday, February 24, 2016 10:01 AM
To: Mike Jones 
<michael.jo...@microsoft.com<mailto:michael.jo...@microsoft.com>>; Phil Hunt 
(IDM) <phil.h...@oracle.com<mailto:phil.h...@oracle.com>>; Nat Sakimura 
<sakim...@gmail.com<mailto:sakim...@gmail.com>>
Cc: <oauth@ietf.org<mailto:oauth@ietf.org>> 
<oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location

> The point of the WGLC is to finish standardizing the core discovery 
> functionality that’s already widely deployed.

That may be widely deployed for OIDC but not widely deployed for OAuth. There 
are some authentication mechanism discovery for endpoint that really should not 
be in an OAuth standard since it’s really not dealt with. Now that all this 
information is available it makes poking around the endpoint more focused for 
people that want to disrupt your endpoints, that is really not addressed in the 
security considerations section at all

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
Sent: Wednesday, February 24, 2016 9:54 AM
To: Phil Hunt (IDM) <phil.h...@oracle.com<mailto:phil.h...@oracle.com>>; Nat 
Sakimura <sakim...@gmail.com<mailto:sakim...@gmail.com>>
Cc: <oauth@ietf.org<mailto:oauth@ietf.org>> 
<oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

The point of the WGLC is to finish standardizing the core discovery 
functionality that’s already widely deployed.

None of Nat or John or I are suggesting that additional related functionality 
won’t be created.  I’m sure it will be.  Some applications will use WebFinger 
to locate the discovery metadata.  Some will possibly use link headers.  Some 
will possibly use application-specific .well-known values.  I’m sure there’s 
other things I haven’t even thought about.  All of these depend upon having a 
discovery metadata document format and none of them change it – other than 
possibly to register additional discovery metadata values.

So by all means, the working group should continue discussing inventing 
possible new related mechanisms that make sense in some contexts.  At the same 
time, we can finish standardizing the already widely deployed core 
functionality that all of these mechanisms will need.

  -- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt (IDM)
Sent: Wednesday, February 24, 2016 8:39 AM
To: Nat Sakimura <sakim...@gmail.com<mailto:sakim...@gmail.com>>
Cc: <oauth@ietf.org<mailto:oauth@ietf.org>> 
<oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

I am suggesting that part of the discovery solution has to be the client 
indicating what resource endpoint it wants the oauth configuration data for.

So if 
res.example.evil.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fres.example.evil.com=01%7c01%7ctonynad%40microsoft.com%7cf6a32a770d6c4f0aaad708d33d437cf9%7c72f988bf86f141af91ab2d7cd011db47%7c1=Pc%2b7ilnDYgfjYoTsQWoZnpobG%2bVJp5Wu9cGpFUgz3S0%3d>
 is not a valid resource endpoint for 
as.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fas.example.com=01%7c01%7ctonynad%40microsoft.com%7cf6a32a770d6c4f0aaad708d33d437cf9%7c72f988bf86f141af91ab2d7cd011db47%7c1=6%2bqxh%2f7VCZkswXhJMv6r%2b18dTRbg2Is12WB%2fdZm3cJ4%3d>
 the authz discovery should fail in some way (eg return nothing).

There may be better ways to do this. Eg combine discovery. Or change the order 
of discovery.

One of OAuth's strength's and weaknesses is that the target of authorization 
(the resource) is never specified. It is often bound up in the client 
registration and an often implied 1:1 relationship between resource and as. 
Given that in discovery phase registration has not yet occurred it seems 
important that the client know it has a valid combination of endpoints etc.

This is why I was disappointed about wglc on discovery. We had a starting point 
for group adoption but we haven't really defined the full requirements IMO.

I am on vacation or I would put some thought into some draft changes

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Anthony Nadalin]

> The point of the WGLC is to finish standardizing the core discovery 
> functionality that’s already widely deployed.
That may be widely deployed for OIDC but not widely deployed for OAuth. There 
are some authentication mechanism discovery for endpoint that really should not 
be in an OAuth standard since it’s really not dealt with. Now that all this 
information is available it makes poking around the endpoint more focused for 
people that want to disrupt your endpoints, that is really not addressed in the 
security considerations section at all

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
Sent: Wednesday, February 24, 2016 9:54 AM
To: Phil Hunt (IDM) ; Nat Sakimura 
Cc:  
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

The point of the WGLC is to finish standardizing the core discovery 
functionality that’s already widely deployed.

None of Nat or John or I are suggesting that additional related functionality 
won’t be created.  I’m sure it will be.  Some applications will use WebFinger 
to locate the discovery metadata.  Some will possibly use link headers.  Some 
will possibly use application-specific .well-known values.  I’m sure there’s 
other things I haven’t even thought about.  All of these depend upon having a 
discovery metadata document format and none of them change it – other than 
possibly to register additional discovery metadata values.

So by all means, the working group should continue discussing inventing 
possible new related mechanisms that make sense in some contexts.  At the same 
time, we can finish standardizing the already widely deployed core 
functionality that all of these mechanisms will need.

  -- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt (IDM)
Sent: Wednesday, February 24, 2016 8:39 AM
To: Nat Sakimura >
Cc: > 
>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

I am suggesting that part of the discovery solution has to be the client 
indicating what resource endpoint it wants the oauth configuration data for.

So if 
res.example.evil.com
 is not a valid resource endpoint for 
as.example.com
 the authz discovery should fail in some way (eg return nothing).

There may be better ways to do this. Eg combine discovery. Or change the order 
of discovery.

One of OAuth's strength's and weaknesses is that the target of authorization 
(the resource) is never specified. It is often bound up in the client 
registration and an often implied 1:1 relationship between resource and as. 
Given that in discovery phase registration has not yet occurred it seems 
important that the client know it has a valid combination of endpoints etc.

This is why I was disappointed about wglc on discovery. We had a starting point 
for group adoption but we haven't really defined the full requirements IMO.

I am on vacation or I would put some thought into some draft changes or a new 
draft. I apologize I can't do it now.

Phil

On Feb 24, 2016, at 08:12, Nat Sakimura 
> wrote:
Hi Phil,

Are you suggesting that the AS metadata should include the RS URIs? Currently, 
it does not, but it can be done, I guess.

The way oauth-meta works is that

1. RS tells the client where the AS is.
2. AS tells the client which RS endpoints the token can be used.

Even if there is a bad AS with a valid certs that proxies to the good RS, the 
client will not send the token there as the authz server will say that is not 
the place the client may want to send the token to.

Nat

2016年2月24日(水) 23:59 Phil Hunt 
>:
Nat,

I’m not sure that having the resource server tell the client where its 
authorization server is secure by itself. The relationship between the 
Authorization Server and the Resource server need to be bound together in one 
of the discovery endpoints (the resource and/or the oauth service discovery).

If a client discovers a fake resource server that is proxying for a real 
resource server the current discovery spec will not lead the client to 
understand it has the wrong resource server. Rather the fake resource service 
will just have a fake discovery service. The hacker can now intercept resource 
payload as well as tokens 

Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption

[Anthony Nadalin]

I hear that many folks don't want to add a mandatory crypto operation on the 
client side :-(

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Tuesday, February 23, 2016 3:17 PM
To: Roland Hedberg 
Cc:  
Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for 
Adoption

The idea of including the state in the PKCE calculation was one I think Hans 
brought up at the meeting in Darmstadt.

I think we discounted it as not solving the problem because the attacker could 
manipulate the code_challenge.

As and example the attacker receives the request and changes the code_challenge 
to one it makes up based on the state from a second request made to the client 
in it’s browser. 

The attacker can replay the token to the client with the state that will 
validate the code_callenge or use the token directly at the token endpoint to 
get a access token as it would know both the client secret and code verifier.

We moved on to look at another way to validate state by passing it to the token 
endpoint for validation to stop the cut and paste attack.

In thinking again about William and Nat’s question about why not PKCE, I looked 
at the idea of using PKCE again.

The problem with using PKCE as it is now is that we made the assumption that 
the attacker could not modify the request.

That got me trying to think of a way to:
 a) stop the attacker from modifying the request (signed request, probably too 
complicated to be generally deployed)
 b) allow the client to detect if code_challenge has been modified and abort of 
the request was compromise.

I realized that you could simply echo back the code_challenge from the 
authorization endpoint and that would allow the client to know if 
code_challenge had been altered in the request, assuming the attacker can’t 
modify the response from the legitimate AS.

So if we add that step we now have a client where code_challenge can’t be 
altered.  

That in it selfs stops the cut and pate attack.  It however still allows an 
attacker to use the code it receives along with the the code_verifier and 
client secret to get a AT and RT from the legitimate token endpoint.

So that is not enough Including state in the hash calculation helps against the 
cut and paste attack but we fixed that by returning code_challenge.

That leaves the other things we were talking about returning from the 
authorization endpoint.

If we include token_endpoint URI in the hash then any token the client requests 
thinking it is for the attackers token endpoint won’t generate the same 
code_challenge as the AS would based on it’s token endpoint.   The attacker 
would know the code_challenge and the real token endpoint URI but would have to 
generate a collision in the lifetime of code to use the code.   This would not 
be possible based on the PKCE analysis.

Returning the code_challenge and including the token_endpoint URI in the hash 
is the minimum needed for the code flow to stop both cut and paste as well  as 
protect the code from being used if stolen via a confused client attack.   It 
doesn’t stop the theft just the use of the token.  So it is mitigating the 
issue a different way from A and B that are trying to stop the attacker from 
getting the code.

Given the technique I realized it would be simple enough to also include some 
other paramaters in the hash
1) The authorization endpoint in the hash causing it not to validate if the 
client has been given a bad authorization endpoint so the client can modify the 
request.  
2) The client_id so that it cannot be tampered with in the request.
3) The state  This is tied to the browser instance for XSRF protection.  
Including this means it cannot be changed and is another protection against cut 
and paste.

Including all 4 in the hash may be overkill as they overlap in protection.  I 
however think that not integrity protecting one of the values might bite us in 
the future.

We could go farther and include scopes or the whole request but that gets more 
complicated than it is worth.  We do have a option for request signing already.

So we almost had this at the Darmstadt meeting but it slipped away.

This is not stoping the attack it is protecting code.   

I should point out that some of the attacks like man in the middling 
registration can still compromise the client secret, making it possible for an 
attacker to impersonate a client.

Nat’s option B doesn’t have a solution to that ether as far as I can tell.

I think the only option for that is to have a logical identifier for the AS and 
some sort of discovery check at registration to be certain that you are using 
the correct registration location.

Option A plus discovery works for that and mitigates confused client but not 
cut and paste.

We still have a problem with AT leaking.   I think that needs to be dealt with 
separately. 
Access tokens should have a 

Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption

[Anthony Nadalin]

I would go with option A, option B introduces concepts/syntax that complicates 
the current Oauth model

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Friday, February 19, 2016 11:43 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption

Early February I posted a mail to the list to make progress on the solution to 
the OAuth Authorization Server Mix-Up problem discovered late last year.

Here is my mail about the Authorization Server Mix-Up:
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2foauth%2fcurrent%2fmsg15336.html=01%7c01%7ctonynad%40microsoft.com%7c9a5edea9bc704239059508d33964d07c%7c72f988bf86f141af91ab2d7cd011db47%7c1=DgIHvagw6YjaIFDFlxp4%2bhgQ7ivmV%2f2FuuuiDwVQRv8%3d

Here is my mail to the list that tries to summarize the discussion status and 
asked a few questions:
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2foauth%2fcurrent%2fmsg15697.html=01%7c01%7ctonynad%40microsoft.com%7c9a5edea9bc704239059508d33964d07c%7c72f988bf86f141af91ab2d7cd011db47%7c1=1EvoWm%2b7K2BSdvTGCDxmzBkmeSo3Wm1GWamgtG6fcNk%3d

Unfortunately, my mail didn't lead to the intended success. While there was 
some feedback I wasn't getting the desired response.

In order to move forward I believe we need a working group document that serves 
as a starting point for further work in the group*. We have two documents that 
provide similar functionality in an attempt to solve the Authorization Server 
Mix-Up problem.

So, here is the question for the group. Which document do you want as a 
starting point for work on this topic:

-- Option A: 'OAuth 2.0 Mix-Up Mitigation' by Mike Jones and John Bradley

Link:
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-jones-oauth-mix-up-mitigation-01=01%7c01%7ctonynad%40microsoft.com%7c9a5edea9bc704239059508d33964d07c%7c72f988bf86f141af91ab2d7cd011db47%7c1=l27GZP9%2bS5BgvlXxSsgJ2cZv66mFbRpdkREO5L%2bcjsQ%3d

-- Option B: 'OAuth Response Metadata' by Nat Sakimura, Nov Matake and Sascha 
Preibisch

Link:
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-sakimura-oauth-meta-07=01%7c01%7ctonynad%40microsoft.com%7c9a5edea9bc704239059508d33964d07c%7c72f988bf86f141af91ab2d7cd011db47%7c1=Bo6qJ%2b7JcAqfRCzAfD4D4oDCOF%2be29RFRLeyWtJP9lg%3d

Deadline for feedback is March, 4th.

Ciao
Hannes & Derek

PS: (*) Regardless of the selected solution we will provide proper 
acknowledgement for those who contributed to the work.

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

Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

[Anthony Nadalin]

Not sure about that. There are things that are "recommended" like the dynamic 
registration endpoint, I don't understand why this is recommended as a lot of 
folks still don't do this. There are security considerations about all the 
information that is in the discovery that have not been addressed.

-Original Message-
From: Mike Jones 
Sent: Thursday, February 18, 2016 10:18 AM
To: Anthony Nadalin <tony...@microsoft.com>; Hannes Tschofenig 
<hannes.tschofe...@gmx.net>; Phil Hunt <phil.h...@oracle.com>; John Bradley 
<ve7...@ve7jtb.com>
Cc: oauth@ietf.org
Subject: RE: [OAUTH-WG] OAuth Discovery spec pared down to its essence

It's the OAuth-specific subset of what's already widely deployed.  Nothing was 
invented - just subsetted.

I think it's already as simple as possible unless the working group decides to 
remove even more functionality (which it can obviously do).

-- Mike

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
Sent: Thursday, February 18, 2016 10:13 AM
To: Hannes Tschofenig <hannes.tschofe...@gmx.net>; Phil Hunt 
<phil.h...@oracle.com>; John Bradley <ve7...@ve7jtb.com>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

I also think we are way far from last call (and surprised to see last call 
issued) on this document as it is still very complex for something that should 
be very simple 

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Thursday, February 18, 2016 6:47 AM
To: Phil Hunt <phil.h...@oracle.com>; John Bradley <ve7...@ve7jtb.com>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence



On 02/18/2016 03:06 PM, Phil Hunt wrote:
> BTW. I think we are FAR from Last Call on this topic.

Thanks for your feedback, Phil. As you have seen I had issued a WGLC prior to 
your message based on the claim from the authors that they believe the document 
is finished.

We will, of course, take all reviews into account and see where we are with the 
discovery spec. I, as the shepherd, will also do my review and I encourage many 
working group members to also take a look at the document and to provide their 
input.

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 Discovery spec pared down to its essence

[Anthony Nadalin]

I also think we are way far from last call (and surprised to see last call 
issued) on this document as it is still very complex for something that should 
be very simple 

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Thursday, February 18, 2016 6:47 AM
To: Phil Hunt ; John Bradley 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence



On 02/18/2016 03:06 PM, Phil Hunt wrote:
> BTW. I think we are FAR from Last Call on this topic.

Thanks for your feedback, Phil. As you have seen I had issued a WGLC prior to 
your message based on the claim from the authors that they believe the document 
is finished.

We will, of course, take all reviews into account and see where we are with the 
discovery spec. I, as the shepherd, will also do my review and I encourage many 
working group members to also take a look at the document and to provide their 
input.

Ciao
Hannes

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

Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-meta-07.txt

[Anthony Nadalin]

I really think that this is a step backwards relative to technology and what 
the developers would accept. The Link Relations takes us back to the XML days, 
I thought we have all moved on from that and at least trying to move Oauth to 
JSON. I think if this were adopted we might be splitting the developers into 
folks that are already going down the current JSON path with Oauth and those 
that want to go back to XML.

This just seems a very odd draft to adopt this technology.

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura
Sent: Monday, February 15, 2016 3:59 PM
To: oauth 
Subject: [OAUTH-WG] Fwd: New Version Notification for 
draft-sakimura-oauth-meta-07.txt

It now shows how to return multiple endpoints in web linking.
Also, added Resource Endpoint response header.

Best,

nat

-- Forwarded message -
From: >
Date: 2016年2月12日(金) 18:40
Subject: New Version Notification for draft-sakimura-oauth-meta-07.txt
To: Nov Matake >, Nat Sakimura 
>, Sascha Preibisch 
>, Sascha 
Preibisch >



A new version of I-D, draft-sakimura-oauth-meta-07.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Name:   draft-sakimura-oauth-meta
Revision:   07
Title:  OAuth Response Metadata
Document date:  2016-02-12
Group:  Individual Submission
Pages:  10
URL:
https://www.ietf.org/internet-drafts/draft-sakimura-oauth-meta-07.txt
Status: 
https://datatracker.ietf.org/doc/draft-sakimura-oauth-meta/
Htmlized:   
https://tools.ietf.org/html/draft-sakimura-oauth-meta-07
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-meta-07

Abstract:
   This specification defines an extensible metadata that may be
   inserted into the OAuth 2.0 responses to assist the clients to
   process those responses.  It is expressed either as a link header, or
   query parameters.  It will allow the client to learn where the
   members in the response could be used, what is the characteristics of
   the payload is, how it should be processed, and so on.  Since they
   are just additional response header/query parameters, any client that
   does not understand this extension should not break and work normally
   while supporting clients can utilize the metadata to take the
   advantage of the extension.




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.

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

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

[Anthony Nadalin]

+1

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of William Denniss
Sent: Wednesday, January 20, 2016 6:30 PM
To: John Bradley ; Phil Hunt (IDM) 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

+1 for adoption, this is important work.

On Thu, Jan 21, 2016, 9:48 AM John Bradley 
> wrote:
+1 for adoption

Mike and I are working on addressing the comments in a new draft for your 
reading pleasure shortly.

John B.

On Jan 20, 2016, at 10:26 PM, Phil Hunt (IDM) 
> wrote:

+1 for adoption

+1 for Brian's comments

Phil

On Jan 20, 2016, at 14:42, Brian Campbell 
> wrote:
I conditionally accept this document as a starting point for work in the OAuth 
working group on the assumption that the considerable simplifications discussed 
and accepted at 
http://www.ietf.org/mail-archive/web/oauth/current/msg15351.html
 will be incorporated.
This document is (should be) intended to provide a mitigation to a security 
problem. As such, it would be nice to see it progress a little faster than the 
typical WG document. The more quickly the document can progress and/or be 
perceived as stable, the better.

On Tue, Jan 19, 2016 at 4:49 AM, Hannes Tschofenig 
> wrote:
Hi all,

this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see
https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00

Please let us know by Feb 9th whether you accept / object to the
adoption of this document as a starting point for work in the OAuth
working group.

Note: This call is related to the announcement made on the list earlier
this month, see
http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html.
 More
time for analysis is provided due to the complexity of the topic.

Ciao
Hannes & Derek


___
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

___
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] Call for adoption: OAuth 2.0 for Native Apps

[Anthony Nadalin]

This work had many issues in the OpenID WG where it failed why should this be a 
WG item here ? The does meet the requirements for experimental, there is a fine 
line between informational and experimental, I would be OK with either but 
prefer experimental, I don’t think that this should become a standard.

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, January 20, 2016 12:11 PM
To: Nat Sakimura 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps

PS as you probably suspected I am in favour of moving this forward.


On Jan 20, 2016, at 5:08 PM, Nat Sakimura 
> wrote:

+1 for moving this forward.

2016年1月21日木曜日、John Bradley>さんは書きました:
Yes more is needed.   It was theoretical at that point.  Now we have 
implementation experience.

On Jan 20, 2016, at 3:38 PM, Brian Campbell 
>
 wrote:

There is 
https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00#appendix-A
 which has some mention of SFSafariViewController and Chrome Custom Tabs.
Maybe more is needed?

On Wed, Jan 20, 2016 at 10:45 AM, John Bradley 
> wrote:
Yes, in July we recommended using the system browser rather than WebViews.

About that time Apple announced Safari view controller and Google Chrome custom 
tabs.   The code in the OS is now stable and we have done a fair amount of 
testing.

The OIDF will shortly be publishing reference libraries for iOS and Android to 
how how to best use View Controllers, and PKCE in native apps on those 
platforms.

We do need to update this doc to reflect what we have learned in the last 6 
months.

One problem we do still have is not having someone with Win 10 mobile 
experience to help document the best practices for that platform.
I don’t understand that platform well enough yet to include anything.

John B.

On Jan 20, 2016, at 12:40 PM, Aaron Parecki 
> wrote:

The section on embedded web views doesn't mention the new iOS 9 
SFSafariViewController which allows apps to display a system browser within the 
application. The new API doesn't give the calling application access to 
anything inside the browser, so it is acceptable for using with OAuth flows. I 
think it's important to mention this new capability for apps to leverage since 
it leads to a better user experience.

I'm sure that can be addressed in the coming months if this document is just 
the starting point.

I definitely agree that a document about native apps is necessary since the 
core leaves a lot of guessing room for an implementation.

For reference, 
https://developer.apple.com/library/prerelease/ios/releasenotes/General/WhatsNewIniOS/Articles/iOS9.html#//apple_ref/doc/uid/TP40016198-DontLinkElementID_26

And see the attached screenshot for an example of what it looks like.




Aaron Parecki
aaronparecki.com
@aaronpk


On Tue, Jan 19, 2016 at 3:46 AM, Hannes Tschofenig 
>
 wrote:
Hi all,

this is the call for adoption of OAuth 2.0 for Native Apps, see
http://datatracker.ietf.org/doc/draft-wdenniss-oauth-native-apps/

Please let us know by Feb 2nd whether you accept / object to the
adoption of this 

Re: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps

[Anthony Nadalin]

After reading this draft I  think that this may be better off as an 
experimental draft and not a WG draft

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Tuesday, January 19, 2016 3:47 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps

Hi all,

this is the call for adoption of OAuth 2.0 for Native Apps, see 
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fdatatracker.ietf.org%2fdoc%2fdraft-wdenniss-oauth-native-apps%2f=01%7c01%7ctonynad%40microsoft.com%7c2180a2867ac74a039d6108d320c642c2%7c72f988bf86f141af91ab2d7cd011db47%7c1=fT7bH5bT8ISndWGCaNj%2f4XGrCz1xFzr0cQdWmGUhk%2fs%3d

Please let us know by Feb 2nd whether you accept / object to the adoption of 
this document as a starting point for work in the OAuth working group.

Note: If you already stated your opinion at the IETF meeting in Yokohama then 
you don't need to re-state your opinion, if you want.

The feedback at the Yokohama IETF meeting was the following: 16 persons for 
doing the work / 0 persons against / 2 persons need more info

Ciao
Hannes & Derek

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

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

[Anthony Nadalin]

I can say on all windows based devices (pc, xbox, phone, etc) with only TPM 1.1 
this will be the approach so it will be commonly used 

-Original Message-
From: John Bradley [mailto:ve7...@ve7jtb.com] 
Sent: Wednesday, November 4, 2015 8:52 PM
To: Anthony Nadalin <tony...@microsoft.com>
Cc: Justin Richer <jric...@mit.edu>; <oauth@ietf.org> <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec 
addressing final shepherd comment

OK, no good reason unless the client is using a HSM that can do HMAC and can 
export a symmetric key wrapped in a asymmetric key provided by the AS.

We don’t currently cover that use case of sending a wrapped symmetric key to 
the AS in POP key distribution.   
I don’t know how common that is going to be, but it is worth thinking about 
defining.

John B.

> On Nov 5, 2015, at 1:45 PM, Anthony Nadalin <tony...@microsoft.com> wrote:
> 
> Not sure why you think its weaker as it would be a wrapped key that 
> the hardware produces
> 
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
> Sent: Wednesday, November 4, 2015 8:43 PM
> To: Justin Richer <jric...@mit.edu>
> Cc: <oauth@ietf.org> <oauth@ietf.org>
> Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs 
> spec addressing final shepherd comment
> 
> In the asymmetric case the use of a HSM or secure element is the argument for 
> the client selecting the public key.   In those cases the client is doing the 
> key gen in hardware so one hopes it is OK.   In the symetric case the client 
> generating the key is weaker (as in I can’t think of any really good reason).
> 
> 
>> On Nov 5, 2015, at 1:35 PM, Justin Richer <jric...@mit.edu> wrote:
>> 
>> I’d argue that it’s best practice, and in line with other parts of OAuth, if 
>> we assume the server generates it in the normal case (issuer -> presenter). 
>> Client generated token keys should be an exception, especially in the 
>> asymmetric case.
>> 
>> — Justin
>> 
>>> On Nov 5, 2015, at 1:32 PM, John Bradley <ve7...@ve7jtb.com> wrote:
>>> 
>>> Agreed the only real difference is the quality of the key.  If the server 
>>> generates it, then it knows that the client is not using the fixed hex 
>>> value of DEADBEEF for everything.
>>> 
>>> John B.
>>>> On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig <hannes.tschofe...@gmx.net> 
>>>> wrote:
>>>> 
>>>> I agree that the effect is the same. From a security point of view 
>>>> there is only an impact if one of the two parties is in a better 
>>>> position to generate random numbers, which is the basis for 
>>>> generating a high entropy symmetric key.
>>>> 
>>>> On 11/04/2015 11:51 PM, Mike Jones wrote:
>>>>> Thanks for the detailed read, Brian.  You’re right that in the 
>>>>> symmetric case, either the issuer or the presenter can create the 
>>>>> symmetric PoP key and share it with the other party, since the effect is 
>>>>> equivalent.
>>>>> I suspect that both the key distribution draft and this draft 
>>>>> should be updated with a sentence or two saying that either 
>>>>> approach can be taken.  Do others concur?
>>>>> 
>>>>> 
>>>>> 
>>>>> -- Mike
>>>>> 
>>>>> 
>>>>> 
>>>>> *From:*Brian Campbell [mailto:bcampb...@pingidentity.com]
>>>>> *Sent:* Thursday, November 05, 2015 7:48 AM
>>>>> *To:* Mike Jones
>>>>> *Cc:* Kepeng Li; oauth@ietf.org
>>>>> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for 
>>>>> JWTs spec addressing final shepherd comment
>>>>> 
>>>>> 
>>>>> 
>>>>> +1 for the diagrams making the document more understandable.
>>>>> 
>>>>> One little nit/question, step 1 in both Symmetric and Asymmetric 
>>>>> keys shows the Presenter sending the key to the Issuer. It's 
>>>>> possible, however, for the key to be sent the other way. Presenter 
>>>>> sending it to the Issuer is probably preferred for asymmetric, 
>>>>> especially if the client can secure the private keys in hardware.
>>>>> But I don't know if one way or the other is clearly better for 
>>>>> symmetric case and PoP key distribution currently has it the oth

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

[Anthony Nadalin]

Not sure why you think its weaker as it would be a wrapped key that the 
hardware produces 

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, November 4, 2015 8:43 PM
To: Justin Richer 
Cc:  
Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec 
addressing final shepherd comment

In the asymmetric case the use of a HSM or secure element is the argument for 
the client selecting the public key.   In those cases the client is doing the 
key gen in hardware so one hopes it is OK.   In the symetric case the client 
generating the key is weaker (as in I can’t think of any really good reason).


> On Nov 5, 2015, at 1:35 PM, Justin Richer  wrote:
> 
> I’d argue that it’s best practice, and in line with other parts of OAuth, if 
> we assume the server generates it in the normal case (issuer -> presenter). 
> Client generated token keys should be an exception, especially in the 
> asymmetric case.
> 
> — Justin
> 
>> On Nov 5, 2015, at 1:32 PM, John Bradley  wrote:
>> 
>> Agreed the only real difference is the quality of the key.  If the server 
>> generates it, then it knows that the client is not using the fixed hex value 
>> of DEADBEEF for everything.
>> 
>> John B.
>>> On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig  
>>> wrote:
>>> 
>>> I agree that the effect is the same. From a security point of view 
>>> there is only an impact if one of the two parties is in a better 
>>> position to generate random numbers, which is the basis for 
>>> generating a high entropy symmetric key.
>>> 
>>> On 11/04/2015 11:51 PM, Mike Jones wrote:
 Thanks for the detailed read, Brian.  You’re right that in the 
 symmetric case, either the issuer or the presenter can create the 
 symmetric PoP key and share it with the other party, since the effect is 
 equivalent.
 I suspect that both the key distribution draft and this draft 
 should be updated with a sentence or two saying that either 
 approach can be taken.  Do others concur?
 
 
 
  -- Mike
 
 
 
 *From:*Brian Campbell [mailto:bcampb...@pingidentity.com]
 *Sent:* Thursday, November 05, 2015 7:48 AM
 *To:* Mike Jones
 *Cc:* Kepeng Li; oauth@ietf.org
 *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for 
 JWTs spec addressing final shepherd comment
 
 
 
 +1 for the diagrams making the document more understandable.
 
 One little nit/question, step 1 in both Symmetric and Asymmetric 
 keys shows the Presenter sending the key to the Issuer. It's 
 possible, however, for the key to be sent the other way. Presenter 
 sending it to the Issuer is probably preferred for asymmetric, 
 especially if the client can secure the private keys in hardware. 
 But I don't know if one way or the other is clearly better for 
 symmetric case and PoP key distribution currently has it the other 
 way 
 .
 Should the intro text somehow mention the possibility that the 
 Issuer could create the key and send it to the Presenter?
 
 I know it's only the introduction but it was just something that 
 jumped out at me.
 
 
 
 
 
 On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones 
 > wrote:
 
 Thanks for suggesting the diagrams, Kepeng. They make the document 
 more understandable.
 
 -- Mike
 
 ---
 -
 
 *From: *Kepeng Li 
 *Sent: *‎11/‎5/‎2015 12:57 AM
 *To: *Mike Jones ; 
 oauth@ietf.org 
 *Subject: *Re: Proof-of-Possession Key Semantics for JWTs spec 
 addressing final shepherd comment
 
 Thank you Mike.
 
 
 
 The diagrams look good to me.
 
 
 
 Kind Regards
 
 Kepeng
 
 
 
 *发件人**: *Mike Jones >
 *日期**: *Thursday, 5 November, 2015 12:32 am
 *至**: *"oauth@ietf.org " >
 *抄送**: *Li Kepeng >
 *主题**: *Proof-of-Possession Key Semantics for JWTs spec addressing 
 final shepherd comment
 
 
 
 

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

[Anthony Nadalin]

Our use case involves mostly hardware (TPM 1.2) based key generation, where the 
hardware (TPM 1.1) is slow we will use secure software execution environment, 
our use case is always client side generated keys

-Original Message-
From: Justin Richer [mailto:jric...@mit.edu] 
Sent: Wednesday, November 4, 2015 8:48 PM
To: Anthony Nadalin <tony...@microsoft.com>
Cc: John Bradley <ve7...@ve7jtb.com>; <oauth@ietf.org> <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec 
addressing final shepherd comment

That’s only if you’re using good hardware to produce a key. We can’t assume 
that’s the only kind of client that will exist, and software generation is 
likely to be much more common for a while yet.

Perhaps what we really need is strong guidance on when to use which approach. 
“If you client has a strong random generator function then you can make your 
own key, but otherwise let the server do it for you."

 — Justin

> On Nov 5, 2015, at 1:45 PM, Anthony Nadalin <tony...@microsoft.com> wrote:
> 
> Not sure why you think its weaker as it would be a wrapped key that 
> the hardware produces
> 
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
> Sent: Wednesday, November 4, 2015 8:43 PM
> To: Justin Richer <jric...@mit.edu>
> Cc: <oauth@ietf.org> <oauth@ietf.org>
> Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs 
> spec addressing final shepherd comment
> 
> In the asymmetric case the use of a HSM or secure element is the argument for 
> the client selecting the public key.   In those cases the client is doing the 
> key gen in hardware so one hopes it is OK.   In the symetric case the client 
> generating the key is weaker (as in I can’t think of any really good reason).
> 
> 
>> On Nov 5, 2015, at 1:35 PM, Justin Richer <jric...@mit.edu> wrote:
>> 
>> I’d argue that it’s best practice, and in line with other parts of OAuth, if 
>> we assume the server generates it in the normal case (issuer -> presenter). 
>> Client generated token keys should be an exception, especially in the 
>> asymmetric case.
>> 
>> — Justin
>> 
>>> On Nov 5, 2015, at 1:32 PM, John Bradley <ve7...@ve7jtb.com> wrote:
>>> 
>>> Agreed the only real difference is the quality of the key.  If the server 
>>> generates it, then it knows that the client is not using the fixed hex 
>>> value of DEADBEEF for everything.
>>> 
>>> John B.
>>>> On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig <hannes.tschofe...@gmx.net> 
>>>> wrote:
>>>> 
>>>> I agree that the effect is the same. From a security point of view 
>>>> there is only an impact if one of the two parties is in a better 
>>>> position to generate random numbers, which is the basis for 
>>>> generating a high entropy symmetric key.
>>>> 
>>>> On 11/04/2015 11:51 PM, Mike Jones wrote:
>>>>> Thanks for the detailed read, Brian.  You’re right that in the 
>>>>> symmetric case, either the issuer or the presenter can create the 
>>>>> symmetric PoP key and share it with the other party, since the effect is 
>>>>> equivalent.
>>>>> I suspect that both the key distribution draft and this draft 
>>>>> should be updated with a sentence or two saying that either 
>>>>> approach can be taken.  Do others concur?
>>>>> 
>>>>> 
>>>>> 
>>>>> -- Mike
>>>>> 
>>>>> 
>>>>> 
>>>>> *From:*Brian Campbell [mailto:bcampb...@pingidentity.com]
>>>>> *Sent:* Thursday, November 05, 2015 7:48 AM
>>>>> *To:* Mike Jones
>>>>> *Cc:* Kepeng Li; oauth@ietf.org
>>>>> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for 
>>>>> JWTs spec addressing final shepherd comment
>>>>> 
>>>>> 
>>>>> 
>>>>> +1 for the diagrams making the document more understandable.
>>>>> 
>>>>> One little nit/question, step 1 in both Symmetric and Asymmetric 
>>>>> keys shows the Presenter sending the key to the Issuer. It's 
>>>>> possible, however, for the key to be sent the other way. Presenter 
>>>>> sending it to the Issuer is probably preferred for asymmetric, 
>>>>> especially if the client can secure the private keys in hardware.
>>>>> But I don't

Re: [OAUTH-WG] confirmation model in proof-of-possession-02

[Anthony Nadalin]

 c72f988bf86f141af91ab2d7cd011db47%7c1sdata=mVCW7aDWJwiUWjKY4XRik1hMJ
 gcxsZO85KRedzj%2bJkY%3d in which he stated that flattening would be 
 a bad direction.  Nat also implicitly endorsed keeping cnf in his 
 WGLC review comments in 
 https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2foauth%2fcurrent%2fmsg14418.html%2cdata=01%7c01%7ctonynad%40microsoft.com%7cc8935ea677b848a37dd308d2a2983ce7%7c72f988bf86f141af91ab2d7cd011db47%7c1sdata=frSZx6RsuShqbRlNtdZRQ6RYWmoCmFaIw%2f3w1LG4sUE%3d
  in his comment Since 'cnf' appears before 3.4, it may be better to bring 
 3.4 at the front.  He suggested changing the location of cnf in the 
 document - not removing it, as Brian's flattening suggestion would have done.

 Tony Nadalin also earlier had spoken about the need to support use 
 cases in which there would be multiple proof-of-possession keys.  
 Among other places, he alluded to this in his note 
 https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.i
 etf.org%2fmail-archive%2fweb%2foauth%2fcurrent%2fmsg14305.htmldata=0
 1%7c01%7ctonynad%40microsoft.com%7cc8935ea677b848a37dd308d2a2983ce7%7
 c72f988bf86f141af91ab2d7cd011db47%7c1sdata=PRG%2b7CdEEQ29m%2fTX9Ne9o
 Xmx2ZR41kWdd9AgBTXCdNo%3d in which he wrote Is this proposal also 
 limited to a single key for both asymmetric and symmetric?.  This is 
 pertinent because as I wrote in the first thread mentioned at 
 https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.i
 etf.org%2fmail-archive%2fweb%2foauth%2fcurrent%2fmsg14856.html%2cdat
 a=01%7c01%7ctonynad%40microsoft.com%7cc8935ea677b848a37dd308d2a2983ce7%7c72f988bf86f141af91ab2d7cd011db47%7c1sdata=Kw6A%2f7tu91fpdG5oyD5sB%2b620Ps%2f6%2b42kc%2fiHzf720I%3d
  Part of the reasoning for using a structured confirmation claim, rather 
 than flattening the confirmation claim into the top-level JWT claims set, is 
 that a JWT may carry more than one conformation key or key descriptor - per 
 Tony's use cases.  John Bradley's note agreeing that flattening would be a 
 bad direction was a response to that.

 -- Mike

 -Original Message-
 From: Kathleen Moriarty [mailto:kathleen.moriarty.i...@gmail.com]
 Sent: Tuesday, August 11, 2015 6:00 AM
 To: Mike Jones
 Cc: Brian Campbell; oauth
 Subject: Re: [OAUTH-WG] confirmation model in proof-of-possession-02

 On Tue, Aug 11, 2015 at 12:08 AM, Mike Jones 
 michael.jo...@microsoft.com
 wrote:
  There didn’t seem to be support for having cnf contain array values.
  Instead, as discussed in the thread “[OAUTH-WG] JWT PoP Key 
  Semantics WGLC followup 3 (was Re: confirmation model in 
  proof-of-possession-02)”, if different keys are being confirmed, 
  they can define additional claims other than “cnf” using the same 
  structure as “cnf” to represent those confirmations.  Indeed, those 
  other claims could be array-valued, if appropriate.  The reasons 
  for having a structured “cnf” claim, rather than a set of flattened 
  claim values, were also discussed in that thread.

 Can you send the link to that thread and the result if it differs 
 from what Brian and Nat agree on?  I'd like to know that there is 
 enough to determine consensus on this point.

 Thanks!
 Kathleen
 
 
 
  Thanks 
  again,
 
  -- Mike
 
 
 
  From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian 
  Campbell
  Sent: Monday, March 23, 2015 9:07 AM
  To: oauth
  Subject: [OAUTH-WG] confirmation model in proof-of-possession-02
 
 
 
  This is mostly about section 3.4 but also the whole draft.
 
 
  If cnf is intended to analogous to the SAML 2.0 
  SubjectConfirmation element, it should probably contain an array 
  value rather than an object value. SAML allows not just for 
  multiple methods of confirming but for multiple instances of the 
  same method. IIRC, only one confirmation needs to be confirmable.
 
  I'm not sure the extra complexity is worth it though. I've rarely, 
  if ever, seen SAML assertions that make use of it.
 
  If the intent is just to allow for different kinds of confirmation, 
  couldn't the structure be pared down and simplified and just have 
  individual claims for the different confirmation types? Like cjwk
  and ckid or similar that have the jwk or kid value respectively 
  as the member value.
 
 
 
 
  ___
  OAuth mailing list
  OAuth@ietf.org
  https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fww
  w.i 
  etf.org%2fmailman%2flistinfo%2foauthdata=01%7c01%7cMichael.Jones%4
  0mi
  crosoft.com%7ca8e38b0ea0334d11e50008d2a24cc573%7c72f988bf86f141af91
  ab2 
  d7cd011db47%7c1sdata=9ukCTugBdbhTVriEoH3HdfMIloD%2fTHYY%2bdPOpQSs7
  x4%
  3d
 



 --

 Best regards,
 Kathleen


 ___
 OAuth mailing list
 OAuth@ietf.org
 https://na01

Re: [OAUTH-WG] Use of Token Exchange spec for API Federation

[Anthony Nadalin]

So in your scenario where you have client (c), user (u), resource (r) and 
resource 1(r1) does the flow go like U-C-R-R1 or U-C-R and U-C-R1 ?

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Chuck Mortimore
Sent: Wednesday, July 15, 2015 12:47 PM
To: OAuth WG oauth@ietf.org; Mike Jones michael.jo...@microsoft.com
Subject: [OAUTH-WG] Use of Token Exchange spec for API Federation

We're examining the use of the Token Exchange spec for API federation 
use-cases, and are looking for some feedback.

The basic use-case is as follows:  Developer wants to build an Application that 
is a composite of backend services that span multiple security domains.   For 
example, it's a combination of Salesforce data and their own backend services.  
   The application is authenticated by Salesforce, and developer wants to 
exchange our ID Token for a token in the second security domain so that login / 
credentials are not required for the second back-end service.

To do this, we're planning to add configuration for multiple audiences in our 
service, allowing the developer to receive a mutli-party ID Token.   We may 
also add custom claims to facilitate mapping of identity across the services.   
Having logged into Salesforce, and received an ID Token, the developer would 
then call a Token Exchange service in the second security domain and exchange 
this ID token for a token specific to that domain.   This allows for simple API 
federation use-cases without converging both APIs / backends on a common token 
format.

Questions / Feedback

1) In the spec, sub is a required field.   However, the application may not 
yet know who the subject is in the second security domain ( it first has to 
exchange the token )One option might be to place the client_id of the 
application as issued by the second security domain, but that seems a bit off.  
 Any advice?   Should this be an Optional field?

2) Speaking of client_ids, if we don't use the sub to transport them, we 
believe the second security domain would still appreciate this context.   The 
Actor field is available, but construction of a full JWT just to transport the 
client_id seems like high overhead, and it may not even be aligned with the 
intent of that field.Should client_id be a claim here?

3) Speaking of Actors, It's not clear what actually states that the jwt 
included in the token is actually an approved actor.Is it intended that the 
act_as or on-behalf_of tokens include an azp authorized party clam as well?

4) Implementations of the specification MUST implement support for using JWTs 
as the Security Tokens.  Other Security Token types MAY be supported.   This 
seems antithetical to the purpose of an STS.   We believe this should be 
relaxed to a SHOULD

Thanks for any feedback here





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

Re: [OAUTH-WG] Token Chaining Use Case

[Anthony Nadalin]

I’m not sure how Brian’s approach solves the basic generic token exchange use 
case that we have

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer
Sent: Tuesday, July 7, 2015 4:47 PM
To: Mike Jones michael.jo...@microsoft.com
Cc: oauth@ietf.org oauth@ietf.org
Subject: Re: [OAUTH-WG] Token Chaining Use Case

This approach is not a good fit for my use cases, and it’s still not  OAuth-y 
at all. It requires a specially-formed security assertion on the way in, which 
the client must understand and generate. I still can’t take an arbitrary token 
I’ve been handed by someone else and pass it off to be pushed forward. The new 
“*_type” parameters seem to merely kick the can down the road instead of 
addressing the problems with the current specification.

I think that Brian’s approach works much better. It unrolls important 
parameters, properly uses the token endpoint, and allows for arbitrarily 
formatted input tokens.

When combined with Nat’s draft that specifies how to perform all generic OAuth 
requests as JWTs (or even some of the upcoming PoP work if we ever do that), 
you’ve pretty much got the draft below but with much more flexibility and power.

 — Justin

On Jul 7, 2015, at 6:51 PM, Mike Jones 
michael.jo...@microsoft.commailto:michael.jo...@microsoft.com wrote:

As just updatedhttp://self-issued.info/?p=1412, I believe that the working 
group token exchange draft 
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02 can now also 
serve the “OAuthy” token exchange use cases, such as Justin and Phil’s token 
chaining use case, as well as support general token exchange, including 
exchange of JWT and SAML tokens.  The mechanism would be the same one that 
Brian suggested below – defining security token type values for OAuth 2.0 
access tokens and refresh tokens – enabling them to be used as inputs and 
outputs in any of the token exchanges.

For instance, by using “access token” as the input security token type, 
providing new scope values, and using “access token” as the output security 
token type, token chaining is achieved.

Now, a question for the working group…  What should the security token type 
values for access token and refresh token be?  Two different choices seem to 
make sense.
(1)  Use the values “access_token” and “refresh_token”, which are used in RFC 
6749 token response values.
(2)  Define new URNs for this usage, such as 
urn:ietf:params:oauth:token-type:access-token and 
urn:ietf:params:oauth:token-type:refresh-token.

I’d personally be fine just using the short names in (1).

If people agree with this approach, we can document this usage in the -03 draft 
and publish it as soon as the submission tool reopens Monday morning during 
IETF 93.

-- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, March 26, 2015 3:15 PM
To: Justin Richer
Cc: oauth@ietf.orgmailto:oauth@ietf.org
Subject: Re: [OAUTH-WG] Token Chaining Use Case

This kind of token exchange might involve exchanges other than swapping an AT 
for another AT (and downscoping it). It might be an AT for a structured JWT 
specifically targeted at one of the the particular services that the original 
RS needs to call. Or an AT might be exchanged for a SAML assertion to use with 
legacy SOAP serveries.  A good general token exchange mechanism enables lots of 
variations of cases like the one Justin mentioned. And more. In fact, I think 
downscoping might be a minority use case where what token exchange is often 
need for is translating tokens from what you have into what the resource you 
need to call can deal with.
There need to be ways for the caller to tell the AS about the token it's asking 
for - by type or by the address/identifier of where it'll be used. There needs 
to be ways for the caller to authenticate to the AS. And there needs to be some 
way of expressing this delegation thing (though I'm still not totally convinced 
it couldn't be just the token is about the user/principal and the caller/client 
of the exchange is who is being delegated to).
I realize few (approaching zero) people have or are going to read it but I have 
endeavored to cover all these things in the 
http://tools.ietf.org/html/draft-campbell-oauth-sts-02 draft. It's an early 
draft so not without it some rough edges but can provide some guidance on what 
is needed and offers some protocol syntax for expressing it. I believe Justin's 
use case would be covered by it (defining a specific token type URI for an 
OAuth access token issued by the AS in question might be needed) as are many 
others.

On Thu, Mar 26, 2015 at 1:31 PM, Justin Richer 
jric...@mit.edumailto:jric...@mit.edu wrote:
As requested after last night’s informal meeting, here is the token chaining 
use case that I want to see represented in the token swap draft.


[ Client ]  -   [ A ] - [ B ] - [ C ]

An OAuth client gets an access token AT1, just 

Re: [OAUTH-WG] JWT Token on-behalf of Use case

[Anthony Nadalin]

The WS-Trust “ActAs” mimics the Windows Kerberos Protocol Transition 
(impersonation)  feature as this enables an account to impersonate another 
account for the purpose of providing access to resources. In a typical 
scenario, the impersonating account would be a service account assigned to a 
web application or the computer account of a web server. The impersonated 
account would be a user account requiring access to resources (e.g. data in an 
SQL database) via a web application. In this scenario, SQL server would be 
accessed by the impersonating (service account) account, however access would 
be under the context of the impersonated (user) account.

WS-Trust “OnBehalfOf”  mimics the Windows Kerberos Constrained Delegation 
feature, which lets you limit the back-end services for which a front-end 
service can request tickets on behalf of another user. “OnBehalfOf”  allows a 
selected services on a server can be granted for access by the impersonating 
account, whilst other services on the same server, or services on other servers 
are denied for access.

Maybe someone can summarize why they think the text for ActAs and OnBehalfOf in 
WS-Trust or Windows Kerberos is wrong or swapped as I have not seen a clear 
explanation other than John saying that Brian knows and Brian saying John knows.

Our usage and use cases are based upon the deployed services of WS-Trust and 
Kerberos support in Windows (workstation and server) and Xbox.

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Monday, July 6, 2015 11:29 AM
To: Mike Jones michael.jo...@microsoft.com
Cc: oauth oauth@ietf.org
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case

Stating specific action items resulting from the ad-hoc meeting in Dallas like 
that suggests some clear consensus was reached, which is not at all the case. 
As I recall, several of us argued past one another for an hour or so and 
decided to adjourn in order to go to the bar (okay, and dinner too - but mostly 
beer).
The impression about reversal of terms, I think, comes from the text in 
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 
which hurts my head a little every-time I read it but does seems to confuse 
things. The MSDN linkhttps://msdn.microsoft.com/en-us/library/ee748487.aspx 
John gave is much more to the point than WS-Trust (I don't believe WS-Trust can 
be pointed to as a model of clarity).  In the draft I wrote, I tried to take 
Mike's text and clarify a distinction between impersonation and delegation with 
https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 and then 
also be very explicit about act-as vs. on-behalf-of in the parameter 
definitions at 
https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 in a manor 
that was consistent with WS-Trust and the MSDN explanation. I could see value 
in breaking with that shaky legacy and using new terms too. But I get the point 
of trying to keep with the old also and potential for even more confusing by 
using new terms.
I wrote draft-campbell-oauth-sts last year in response to the call for adoption 
of jones-oauth-token-exchange (thread from the 
archivehttps://www.ietf.org/mail-archive/web/oauth/current/msg13305.html). 
Though I didn't try and stand in the way and indicated a willingness to 
collaborate on things. With the expectation, of course, that the details would 
differ from the -00s and -01s as work progressed. Folks seemed generally 
amenable to 
thathttps://www.ietf.org/mail-archive/web/oauth/current/msg13308.html at the 
time but little has happened since then.
Phil's earlier point about the priory of this getting pushed down has some 
truth to it. But I still believe it's something that can provide a lot of value 
in standardizing, if we do so in a reasonable way.





On Mon, Jul 6, 2015 at 10:33 AM, Mike Jones 
michael.jo...@microsoft.commailto:michael.jo...@microsoft.com wrote:
It would surprise me if on-behalf-of and act-as were reversed with respect 
WS-Trust, because the explanations of the terms came directly from WS-Trust 
1.4.  I also think the chances of us reducing confusion by inventing new 
terminology, rather than adding to it, would not be in our favor. :-/

FYI, the action items outstanding from our ad-hoc meeting on this draft in 
Dallas are:
  - Allowing security types other than JWT to also be used as the act_as and 
on_behalf_of request values.
  - Further integrating the mechanism into the existing OAuth ecosystem - 
allowing use of access tokens or refresh tokens when appropriate.

I plan to do the first today.  The second is probably more than I'll get done 
today before the submission cutoff.  I agree with John that it would be useful 
to have discussions on this in Prague on the best way to achieve this further 
integration.  I'll plan to come into the Prague meeting with a concrete 
proposal for review.

Best wishes,
-- Mike

Re: [OAUTH-WG] JWT Token on-behalf of Use case

[Anthony Nadalin]

What is written in 
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 and 
the text that describes the Windows Kerberos support for Protocol Transition 
and Constrained Delegation are in alignment not sure what make you think they 
are not.

If you are trying to describe different features than Windows Kerberos Protocol 
Transition/Constrained Delegation that then I would agree that the text may not 
be correct but then again it would not be describing the Windows Kerberos 
Protocol Transition/Constrained Delegation. The way you have the text describes 
different set use case then what the feature of  
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 
describes.

From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Monday, July 6, 2015 2:33 PM
To: Anthony Nadalin tony...@microsoft.com
Cc: Mike Jones michael.jo...@microsoft.com; oauth oauth@ietf.org
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case

A natural usage of act-as or 
impersonationhttp://www.oxforddictionaries.com/us/definition/american_english/impersonate
 would suggest, to many people anyway, that the way you just used the terms is 
reversed. The bold text below from 
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 uses 
'impersonates' and on-behalf-of contrary to what you just wrote about Windows 
Kerb. That's where the assertion that the draft has them reversed from de facto 
usage in WS-Trust. Those semantics are not only one open issue that needs to be 
resolved, however, even if they occupy most of the discussion.

1.3.  On-Behalf-Of vs. Impersonation Semantics

   When principal A acts on behalf of principal B, A is given all the
   rights that B has within some defined rights context.  Whereas, with
   on-behalf-of semantics, principal A still has its own identity
   separate from B and it is explicitly understood that while B may have
   delegated its rights to A, any actions taken are being taken by A and
   not B. In a sense, A is an agent for B.

   On-behalf-of semantics are therefore different than impersonation
   semantics, with which it is sometimes confused.  When principal A
   impersonates principal B, then in so far as any entity receiving
   Claims is concerned, they are actually dealing with B. It is true
   that some members of the identity system might have awareness that
   impersonation is going on but it is not a requirement.  For all
   intents and purposes, when A is acting for B, A is B.





On Mon, Jul 6, 2015 at 2:43 PM, Anthony Nadalin 
tony...@microsoft.commailto:tony...@microsoft.com wrote:
The WS-Trust “ActAs” mimics the Windows Kerberos Protocol Transition 
(impersonation)  feature as this enables an account to impersonate another 
account for the purpose of providing access to resources. In a typical 
scenario, the impersonating account would be a service account assigned to a 
web application or the computer account of a web server. The impersonated 
account would be a user account requiring access to resources (e.g. data in an 
SQL database) via a web application. In this scenario, SQL server would be 
accessed by the impersonating (service account) account, however access would 
be under the context of the impersonated (user) account.

WS-Trust “OnBehalfOf”  mimics the Windows Kerberos Constrained Delegation 
feature, which lets you limit the back-end services for which a front-end 
service can request tickets on behalf of another user. “OnBehalfOf”  allows a 
selected services on a server can be granted for access by the impersonating 
account, whilst other services on the same server, or services on other servers 
are denied for access.

Maybe someone can summarize why they think the text for ActAs and OnBehalfOf in 
WS-Trust or Windows Kerberos is wrong or swapped as I have not seen a clear 
explanation other than John saying that Brian knows and Brian saying John knows.

Our usage and use cases are based upon the deployed services of WS-Trust and 
Kerberos support in Windows (workstation and server) and Xbox.

From: OAuth [mailto:oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org] On 
Behalf Of Brian Campbell
Sent: Monday, July 6, 2015 11:29 AM
To: Mike Jones michael.jo...@microsoft.commailto:michael.jo...@microsoft.com
Cc: oauth oauth@ietf.orgmailto:oauth@ietf.org

Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case

Stating specific action items resulting from the ad-hoc meeting in Dallas like 
that suggests some clear consensus was reached, which is not at all the case. 
As I recall, several of us argued past one another for an hour or so and 
decided to adjourn in order to go to the bar (okay, and dinner too - but mostly 
beer).
The impression about reversal of terms, I think, comes from the text in 
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 
which hurts my head a little every-time I read it but does seems to confuse 
things. The MSDN linkhttps://msdn.microsoft.com

Re: [OAUTH-WG] JWT Token on-behalf of Use case

[Anthony Nadalin]

Not quite, the actual tokens are still opaque, the requestor is just asking for 
a token exchange , the requestor can specify the requested token type it's up 
to the server to determine the actual token it will delever

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer
Sent: Wednesday, July 1, 2015 5:18 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case

As it's written right now, it's a translation of some WS-* concepts into JWT 
format. It's not really OAuth-y (since the client has to understand the token 
format along with everyone else, and according to the authors the artifacts 
might not even be OAuth tokens), and that's my main issue with the document. 
Years ago, I proposed an OAuth-based token swap
mechanism:

https://tools.ietf.org/html/draft-richer-oauth-chain-00

This works without defining semantics of the tokens themselves, just like the 
rest of OAuth. I've proposed to the authors of the current draft that it should 
incorporate both semantic (using JWT) and syntactic (using a simple 
token-agnostic grant) token swap mechanisms, and that the two could be easily 
compatible.

  -- Justin

On 7/1/2015 6:35 AM, Sergey Beryozkin wrote:
 Hmm... perhaps the clue is in the draft title, token-exchange, so may 
 be it is a case of the given access token (on_behalf_of or act_as
 claim) being used to request a new security token. One can only guess 
 though, does not seem like the authors are keen to answer the newbie 
 questions...

 Cheers, Sergey


 On 30/06/15 13:38, Sergey Beryozkin wrote:
 Hi,
 Can you please explain what is the difference between On-Behalf-Of 
 semantics described in the draft-ietf-oauth-token-exchange-01 and the 
 implicit On-Behalf-Of semantics a client OAuth2 token possesses ?

 For example, draft-ietf-oauth-token-exchange-01 mentions:

 Whereas, with on-behalf-of semantics, principal A still has its own 
 identity separate from B and it is explicitly understood that while B 
 may have delegated its rights to A, any actions taken are being taken 
 by A and not B. In a sense, A is an agent for B.

 This is a typical case with the authorization code flow where a 
 client application acts on-behalf-of the user who authorized this 
 application ?

 Sorry if I'm missing something

 Cheers, Sergey
 On 25/06/15 22:28, Mike Jones wrote:
 That's what
 https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 is 
 about.

 Cheers,

 -- Mike

 *From:*OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Vivek 
 Biswas -T (vibiswas - XORIANT CORPORATION at Cisco)
 *Sent:* Thursday, June 25, 2015 2:20 PM
 *To:* OAuth@ietf.org
 *Subject:* [OAUTH-WG] JWT Token on-behalf of Use case

 Hi All,

I am looking to solve a use-case similar to WS-Security 
 On-Behalf-Of 
 http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-trust
 -1.4-errata01-os-complete.html#_Toc325658980


 with OAuth JWT Token.

Is there a standard claim which we can define within the OAuth 
 JWT which denote the On-behalf-of User.

 For e.g., a Customer Representative trying to create token on behalf 
 of a customer and trying to execute services specific for that 
 specific customer.

 Regards,

 Vivek Biswas,
 CISSP

 *Cisco Systems, Inc http://www.cisco.com/*

 *Bldg. J, San Jose, USA,*

 *Phone: +1 408 527 9176*



 ___
 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

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

Re: [OAUTH-WG] JWT Destination Claim

[Anthony Nadalin]

There some folks out there that are using AUD to mean DST. Adding DST is 
confusing, if you want to use it that's fine but don't see a need to 
standardize every claim that someone comes up with

Sent from my Windows Phone

From: Brian Campbellmailto:bcampb...@pingidentity.com
Sent: ‎3/‎25/‎2015 2:19 PM
To: Mike Jonesmailto:michael.jo...@microsoft.com
Cc: oauthmailto:oauth@ietf.org
Subject: Re: [OAUTH-WG] JWT Destination Claim

FWIW, I did have that as an open issue in the draft: 
http://tools.ietf.org/html/draft-campbell-oauth-dst4jwt-00#appendix-A

Though the way I worded it probably shows my bias.

On Wed, Mar 25, 2015 at 2:16 PM, Mike Jones 
michael.jo...@microsoft.commailto:michael.jo...@microsoft.com wrote:
Thanks for posting this, Brian.  To get it down on the list, I’ll repeat my 
comment made in person that just as “aud” used to be single-valued and ended up 
being multi-valued, I suspect some applications would require the same thing of 
“dst” – at least when “aud” and “dst” are different.  And even if “dst” becomes 
multi-valued, it’s OK for particular applications to require that it be 
single-valued in their usage.

-- Mike

From: OAuth [mailto:oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org] On 
Behalf Of Brian Campbell
Sent: Wednesday, March 25, 2015 2:08 PM
To: oauth
Subject: [OAUTH-WG] JWT Destination Claim

Here are the slides that I rushed though at the end of the Dallas meeting:
https://www.ietf.org/proceedings/92/slides/slides-92-oauth-1.pdf

And the -00 draft:
http://tools.ietf.org/html/draft-campbell-oauth-dst4jwt-00
In an informal discussion earlier this week John B. suggested that some 
additional thinking and/or clarification is needed with regard to what parts of 
the URI to include and check. Particularly with respect to query and fragment. 
And he's probably right.

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

[OAUTH-WG] Token Introspection: Misc Review Comments

[Anthony Nadalin]

Some comments:

 The endpoint MAY allow other parameters to provide further context to the 
 query.

If the endpoint does not understand these the endpoint must ignore.

The only MUST in this specification is to return the active Boolean, but this 
is still underspecified as there is no definition or criteria that a developer 
has to go upon to determine if that Boolean is set or not.

token_type_hint  is really not a type hint but just a token hint and thus 
should be chnaged

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

Re: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open Issues before the Deadline

[Anthony Nadalin]

This can't be limited to JWE Compact Serialization, we have keys that use the 
JSON binary serialization.

cnf seems underspecified, as this could be a JWK (but not it's not a MUST), 
and thus I may understand cnf but only when used with a JWK and not some 
other invented structure. So how do I tell what cnf really is ?

Is this proposal also limited to a single key  for both asymmetric and 
symmetric  ?

-Original Message-
From: Mike Jones 
Sent: Wednesday, March 4, 2015 3:34 PM
To: Anthony Nadalin; Hannes Tschofenig; oauth@ietf.org
Subject: RE: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open 
Issues before the Deadline

It does so for the same reason that the JWT spec does - to promote 
interoperability.  We can add wording along the likes of the JWE Compact 
Serialization MUST be used if you like.

-- Mike

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
Sent: Wednesday, March 04, 2015 3:26 PM
To: Hannes Tschofenig; oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open 
Issues before the Deadline

Why does the specification state encrypted to a key known to the recipient 
using the JWE Compact Serialization is this the only serialization allowed 
(there is no MUST) ?
containing the symmetric key.

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Wednesday, March 4, 2015 6:41 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open 
Issues before the Deadline

Hi all,

as the deadline is approaching I would like to close the open issues of the 
document. There are two open issues listed in the document and I propose ways 
to resolve them below

Open Issue #1:

In some conversations, we have said that it is the issuer of the JWT
   that possesses the key, and in some conversations, we have said that
   it is the presenter of the JWT that possesses the key.  Which
   description should we use?


There are the following parties in the entire picture (as the PoP architecture 
document illustrates quite nicely):

* Issuer: Party that creates the JWT and binds a key to the token.
The key may be a symmetric key or a public key. To bind the key to the JWT the 
issuer needs to compute a digital signature or a keyed message digest over the 
JWT.

* Presenter: Party that demonstrates possession of a private key (for 
asymmetric key cryptography) and secret key (for symmetric key
cryptography) to a recipient.

* Recipient: Party that receives the JWT together with the proof of possession 
of the key (typically in form of a digital signature or a keyed message digest).

Mapping this terminology to the OAuth context would look as follows:
 - Issuer: OAuth Authorization Server
 - Presenter: OAuth Client
 - Recipient: OAuth Resource Server

Adding the above-mentioned terminology to the terminology section (and deleting 
the currently listed presenter) would resolve the issue IMHO.

Open Issue#2:

Mike added an editorial note to the introduction saying:

 [[ Editorial Note: This paragraph needs to be updated to provide more
   context and possibly also to describe the use of asymmetric keys
   instead.  It's not clear that the symmetric case is as useful or
   valuable, and it is certainly more complicated.]] 

The design team work clearly indicated that both symmetric and asymmetric 
cryptography has to be supported. The JWT mechanism actually supports both and 
hence we should also describe both. What can, however, be done is to also 
describe the asymmetric key case and here is my text proposal for the 
introduction.


1.  Introduction

   This specification defines how to bind a key to a JSON Web
   Token (JWT) [JWT]. Three parties act in such a scenario:

* Issuer: Party that creates the JWT and binds a key to the token.
The key may be a symmetric key or a public key. To bind the key to the JWT the 
issuer needs to compute a digital signature or a keyed message digest over the 
JWT.

* Presenter: Party that demonstrates possession of a private key (for 
asymmetric key cryptography) and secret key (for symmetric key cryptography) to 
a recipient. This property is also sometimes described as the presenter being a 
holder-of-key.

* Recipient: Party that receives the JWT together with the proof of possession 
of the key (typically in form of a digital signature or a keyed message digest).

[I-D.ietf-oauth-pop-architecture] describes the use of proof-of-possession 
semantics for JSON Web Tokens (JWTs) for the use with OAuth.

   Envision the following two use cases. The first use case describes
   the use of a symmetric key and the second use case focuses on
   asymmetric cryptography.

   An OAuth 2.0 authorization server generates a JWT
   and places an encrypted symmetric key inside the newly introduced
   confirmation claim.  This symmetric key is encrypted with a key

Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection Claims

[Anthony Nadalin]

The definition of “active” is really up to the authorization server, and I’ve 
yet to hear from an actual implementor who’s confused by this definition. When 
you’re the one issuing the tokens, you know what an “active” token means to you

According to the spec as written the Introspection endpoint does not have to be 
an Authorization Sever and thus each could have defined “active” in different 
ways

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer
Sent: Wednesday, March 4, 2015 1:46 PM
To: Hannes Tschofenig
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection Claims

Hi Hannes, thanks for the feedback. Responses inline.

On Mar 3, 2015, at 5:56 AM, Hannes Tschofenig 
hannes.tschofe...@gmx.netmailto:hannes.tschofe...@gmx.net wrote:

Hi Justin, Hi all,

in OAuth we provide two ways for a resource server to make an
authorization decision.

1) The resource server receives a self-contained token that contains all
the necessary information to make a local authorization decision. With
the JWT we have created such a standardized information and data model.

2) With an access request from a client the resource server asks the
authorization server for help. The authorization server provides
information that help make the authorization decision. This is the token
introspection approach.

I believe the two approaches need to be aligned with regard to the
information and the data model. Since both documents already use JSON as
a way to encode information (=data model) and almost have an identical
information model (the data that is being passed around).

What needs to be done?

* Use the term 'claims' in both documents.
* Use the same registry (i.e., the registry established with the JWT).
* Register the newly defined claims from the token introspection
document in the claims registry.

We’ve already done this in the latest draft. Or at least, that’s the intent of 
the current text — the registry is referenced and the new claims are 
registered. Can you specifically point to places where this needs to be 
improved upon?


Then, I have a few comments on the new claims that are proposed:

Here is the definition of the 'active' claim:

  active
 REQUIRED.  Boolean indicator of whether or not the presented token
 is currently active.  The authorization server determines whether
 and when a given token is in an active state.

This claim is not well-defined. You need to explain what active means.
It could, for example, mean that the token is not yet expired. Then,
there is of course the question why you are not returning the 'exp'
claim together with the 'nbf' claim.

The definition of “active” is really up to the authorization server, and I’ve 
yet to hear from an actual implementor who’s confused by this definition. When 
you’re the one issuing the tokens, you know what an “active” token means to 
you. Still, perhaps we can be even more explicit, such as:


active
  REQUIRED. Boolean indicator of whether or not the presented token is 
currently active. The specifics of a token’s active state will vary depending 
on the implementation of the authorization server, but generally this will 
indicate that a given token has been issued by this authorization server, has 
not been revoked by the resource owner, and is within its given time window of 
validity (e.g. not expired).

Also, this is one of the places where the overlap between JWT and introspection 
claims don’t make sense. It doesn’t make any sense for a JWT to carry an 
“active” claim at all. Why would you have a JWT claim to be anything but 
active? We should register it with the JWT registry to avoid name collisions, 
but there’s nothing in the JWT registry that says “don’t use this inside of a 
JWT”. Do you have any advice on how to address this?



client_id: What is the resource server going to do with the client_id?
What authorization decision could it make?

Whatever it wants to. If an RS can figure out something from the client_id, why 
not let it? The client_id is a piece of information about the context of the 
issuance of the token, and a common enough OAuth value for decision making.


I have a couple of reactions when I read the 'user_id' claim:
 - I believe the inclusion of a user id field in the response could
lead to further confusion regarding OAuth access token usage for
authentication.

This isn’t any different from having a userinfo-endpoint equivalent (like 
social graph or twitter API) and it’s got the same trouble.



 - Since you define it as a human readable identifier I am wondering
whether you want to say something about the usage. Here it seems that it
might be used for displaying something on a webpage rather than making
an authorization decision but I might well be wrong.

We added in “user_id” to our implementation due to developer demand — they 
wanted a username associated with the return value, but to leave the “sub” 
value the same as that defined by OpenID 

Re: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open Issues before the Deadline

[Anthony Nadalin]

Why does the specification state encrypted to a key known to the recipient 
using the JWE Compact Serialization is this the only serialization allowed 
(there is no MUST) ?
containing the symmetric key.

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Wednesday, March 4, 2015 6:41 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open 
Issues before the Deadline

Hi all,

as the deadline is approaching I would like to close the open issues of the 
document. There are two open issues listed in the document and I propose ways 
to resolve them below

Open Issue #1:

In some conversations, we have said that it is the issuer of the JWT
   that possesses the key, and in some conversations, we have said that
   it is the presenter of the JWT that possesses the key.  Which
   description should we use?


There are the following parties in the entire picture (as the PoP architecture 
document illustrates quite nicely):

* Issuer: Party that creates the JWT and binds a key to the token.
The key may be a symmetric key or a public key. To bind the key to the JWT the 
issuer needs to compute a digital signature or a keyed message digest over the 
JWT.

* Presenter: Party that demonstrates possession of a private key (for 
asymmetric key cryptography) and secret key (for symmetric key
cryptography) to a recipient.

* Recipient: Party that receives the JWT together with the proof of possession 
of the key (typically in form of a digital signature or a keyed message digest).

Mapping this terminology to the OAuth context would look as follows:
 - Issuer: OAuth Authorization Server
 - Presenter: OAuth Client
 - Recipient: OAuth Resource Server

Adding the above-mentioned terminology to the terminology section (and deleting 
the currently listed presenter) would resolve the issue IMHO.

Open Issue#2:

Mike added an editorial note to the introduction saying:

 [[ Editorial Note: This paragraph needs to be updated to provide more
   context and possibly also to describe the use of asymmetric keys
   instead.  It's not clear that the symmetric case is as useful or
   valuable, and it is certainly more complicated.]] 

The design team work clearly indicated that both symmetric and asymmetric 
cryptography has to be supported. The JWT mechanism actually supports both and 
hence we should also describe both. What can, however, be done is to also 
describe the asymmetric key case and here is my text proposal for the 
introduction.


1.  Introduction

   This specification defines how to bind a key to a JSON Web
   Token (JWT) [JWT]. Three parties act in such a scenario:

* Issuer: Party that creates the JWT and binds a key to the token.
The key may be a symmetric key or a public key. To bind the key to the JWT the 
issuer needs to compute a digital signature or a keyed message digest over the 
JWT.

* Presenter: Party that demonstrates possession of a private key (for 
asymmetric key cryptography) and secret key (for symmetric key cryptography) to 
a recipient. This property is also sometimes described as the presenter being a 
holder-of-key.

* Recipient: Party that receives the JWT together with the proof of possession 
of the key (typically in form of a digital signature or a keyed message digest).

[I-D.ietf-oauth-pop-architecture] describes the use of proof-of-possession 
semantics for JSON Web Tokens (JWTs) for the use with OAuth.

   Envision the following two use cases. The first use case describes
   the use of a symmetric key and the second use case focuses on
   asymmetric cryptography.

   An OAuth 2.0 authorization server generates a JWT
   and places an encrypted symmetric key inside the newly introduced
   confirmation claim.  This symmetric key is encrypted with a key known
   only to the authorization server and the recipient. The entire JWT
   is then integrity protected.  The JWT is then sent to the
   presenter.  Since the presenter is unable to obtain the
   encrypted symmetric key from the JWT itself, the authorization
   server conveys that symmetric key separately to the presenter.  Now,
   the presenter is in possession of the symmetric key as well as the
   JWT (which includes the confirmation claim member).  When the
   presenter needs to present the JWT to the recipient, it also needs
   to demonstrate possession of the symmetric key; the presenter, for
   example, uses the symmetric key in a challenge/response protocol
   with the recipient.  The recipient is able to verify that it is
   interacting with the genuine presenter by decrypting the JWK
   contained inside the confirmation claim of the JWT.  By doing this
   the recipient obtains the symmetric key, which it then uses to
   verify cryptographically protected messages exchanged with the
   presenter.

   This symmetric key mechanism described above is conceptually similar
   to the use of Kerberos tickets.

   In the second case consider a 

Re: [OAUTH-WG] draft-ietf-oauth-introspection

[Anthony Nadalin]

1.   Answer is still unclear, Is the metadata (introspection response) 
being returned from the authorization endpoint or from the token or a 
combination of both ? The answer needs to go in the spec

2.   Spec needs to contain this information about stateless tokens

3.   For interoperability there needs to be an understanding of what token 
types this specification supports, we already know some token types that may 
not work

4.   I'm not issuing an Oauth encrypted token as it's just a bearer token, 
just happens to be a an encrypted SAML token, which I don't know since I'm a 
client that can't understand what is in token

5.   I would propose wording but I'm still trying to figure out what 
active means so that everyone implementing this has the same understanding, I 
did not see a definition of active in the specification.

What about the Audience restricted tokens, do you expect the endpoint to ignore 
this and process the tokens for metadata ?

From: Justin Richer [mailto:jric...@mit.edu]
Sent: Monday, December 1, 2014 4:42 PM
To: Anthony Nadalin
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-ietf-oauth-introspection


1.   Is the metadata (introspection response) being returned from the 
authorization endpoint or from the token or a combination of both ?

As I said below, ultimately it's about the token and what it represents. If the 
token was issued through use of the authorization endpoint, then it's likely 
that there's some context from that authorization endpoint tied to the token 
that can be returned.



2.   context there may be no context other than the token, are you 
expecting the authorization endpoint to always keep a context of how/why the 
token was issued ?

If you're asking if stateless tokens can be supported with this, then yes, 
that's fine. If the token's completely on its own (like a structured token 
generated as an assertion and used as an OAuth 2.0 access token) and a server's 
able to unpack that for a client without access to other pieces of context, 
then that's what it returns. But in that case, if you're issuing stateless 
tokens, with self-contained metadata and expirations and no other context to be 
conveyed beyond what's already inside the token, then you'd probably just tell 
your protected resources how to parse and handle them directly.



3.   The specification should clearly state which type of tokens are 
supported and what profiles/bindings are supported, like JWT Bearer, etc.

That's opaque to the protected resource for purposes of this protocol, just 
like a token is opaque to a client for purposes of 6749/6750 OAuth. The 
introspection protocol supports whatever tokens are supported by the AS, so we 
don't need to list token types, but maybe we can be clearer about the 
opaqueness of the token value in this process. Since these are OAuth tokens and 
not assertions, no bindings or profiles are needed beyond this. It's a simple 
query-response and it's up to the server to know how to fulfill this contract.



4.   If I have an SAML Bearer assertion, and the SAML assertion is 
encrypted and have no way to know this, it can potentially fail if it can't be 
decrypted but as far as I can tell I'm not sending an encrypted token since 
this is just a SAML assertion, not sure how one really determines what is wrong

If the AS can't decrypt the token then it can't introspect it. So it doesn't in 
this case. And if you're issuing encrypted OAuth tokens with no means to 
decrypt them back at the AS, then you probably wouldn't offer an introspection 
service to begin with. This is covered in the security considerations section 
already.



5.   Should be spelled out what active is supposed to mean so folks get 
the same results on different endpoints

As I said below, it means to answer is this token still good or not? for a 
protected resource that can't answer that on its own, and I believe the current 
definition reflects that. Please submit text if the existing definition is 
insufficient or unclear to you.

 - Justin





From: Justin Richer [mailto:jric...@mit.edu]
Sent: Sunday, November 30, 2014 6:57 PM
To: Anthony Nadalin
Cc: oauth@ietf.orgmailto:oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-ietf-oauth-introspection

Tony, thanks for the comments. Your timing is great, as I was just today 
sitting down to polish the introspection draft into a proper WG document ready 
for the last-call tomorrow. I've just posted the updated draft, and I think 
that you'll find it addresses your concerns. More direct answers inline:


On Nov 30, 2014, at 1:01 PM, Anthony Nadalin 
tony...@microsoft.commailto:tony...@microsoft.com wrote:



Comments

Intro
about the authentication conext, not sure what this is since there is no 
authentication context in Oauth

There are several authentication contexts in OAuth: the resource owner at the 
authorization endpoint, the client at the token endpoint, etc. Regardless, this 
is meant

Re: [OAUTH-WG] draft-ietf-oauth-introspection

[Anthony Nadalin]

Thanks for the update, there are still some unclear points


1.   Is the metadata (introspection response) being returned from the 
authorization endpoint or from the token or a combination of both ?

2.   context there may be no context other than the token, are you 
expecting the authorization endpoint to always keep a context of how/why the 
token was issued ?

3.   The specification should clearly state which type of tokens are 
supported and what profiles/bindings are supported, like JWT Bearer, etc.

4.   If I have an SAML Bearer assertion, and the SAML assertion is 
encrypted and have no way to know this, it can potentially fail if it can't be 
decrypted but as far as I can tell I'm not sending an encrypted token since 
this is just a SAML assertion, not sure how one really determines what is wrong

5.   Should be spelled out what active is supposed to mean so folks get 
the same results on different endpoints



From: Justin Richer [mailto:jric...@mit.edu]
Sent: Sunday, November 30, 2014 6:57 PM
To: Anthony Nadalin
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-ietf-oauth-introspection

Tony, thanks for the comments. Your timing is great, as I was just today 
sitting down to polish the introspection draft into a proper WG document ready 
for the last-call tomorrow. I've just posted the updated draft, and I think 
that you'll find it addresses your concerns. More direct answers inline:


On Nov 30, 2014, at 1:01 PM, Anthony Nadalin 
tony...@microsoft.commailto:tony...@microsoft.com wrote:


Comments

Intro
about the authentication conext, not sure what this is since there is no 
authentication context in Oauth

There are several authentication contexts in OAuth: the resource owner at the 
authorization endpoint, the client at the token endpoint, etc. Regardless, this 
is meant to be the context of the authorization decision, text now reads: 
context in which the token was issued


Use of Oauth2, mixed with use of Oauth, pick one

All usage changed to OAuth 2.0 throughout the document, let me know if I 
missed any.


allows holder of a token to query so anything/anyone that has a token can use 
this endpoint?

Now reads authorized holder of the token and has stronger language and 
recommendations about requiring authorization on the endpoint to prevent public 
token fishing. This was already addressed in the security considerations 
section, but that has been propagated throughout the specification now.



Introspection Endpoint
Use of Oauth2, mixed with use of Oauth, pick one


See above.



Introspection Request
The endpoint SHOULD also require some form of authentication, what about some 
form of authorization ? Why do we have to have another endpoint that we have to 
manage and then have a management API draft?]

This is now clearer that it needs to be an authorized protected resource. This 
authorization may be carried through a credential mechanism as defined in OAuth 
2.0, through an access token, or through some other mechanism.



Token - is this any type of token ? how does the endpoint know that it can deal 
with this token type?

Clarified that it's either the access_token from the token endpoint or the 
refresh_token from the token endpoint. You can use this with other token types, 
but that's not defined in this spec which concerns itself with RFC6749/RFC6750.


So endpoint has to try to lookup token  to determine if it can maybe find out 
something about the token?

That's the idea, the protected resource is asking an authoritative source (the 
authorization server) about a given token. I had always thought it was obvious 
that the authorization server would have to be able to know something about the 
token in order to provide an introspection service, but since that seems to 
have been unclear to some I've made it explicit in the security considerations 
section.


Can the one use the authorization code or does one have to get a token first?

No, this is for tokens only. I don't see the point of introspecting an 
authorization code - those aren't sent to protected resources, they're sent to 
clients, which would in turn just hand it to the token endpoint to get a token. 
There's nothing else to find out about it.


 Can I send a encrypted token and expect a proper response ?

If the server can decrypt or otherwise understand the token, yes. I've pointed 
out this requirement in the security considerations section.


What about a Proof of Possession Token?

Yes, I think this fits great with PoP tokens, but those aren't defined well 
enough yet to say anything concrete. As the PoP work progresses, we can have an 
extension document to determine what needs to be done there. Note that we'll 
have to do the same thing with the Revocation RFC.


 Introspection Response
What is active mean ? Is this up to the server to determine ?

It means the token is live, hasn't been revoked, was actually issued by this 
server, isn't expired, and the protected resource that's

[OAUTH-WG] draft-ietf-oauth-introspection

[Anthony Nadalin]

Comments

Intro
about the authentication conext, not sure what this is since there is no 
authentication context in Oauth
Use of Oauth2, mixed with use of Oauth, pick one
allows holder of a token to query so anything/anyone that has a token can use 
this endpoint?

Introspection Endpoint
Use of Oauth2, mixed with use of Oauth, pick one

Introspection Request
The endpoint SHOULD also require some form of authentication, what about some 
form of authorization ? Why do we have to have another endpoint that we have to 
manage and then have a management API draft?]

Token - is this any type of token ? how does the endpoint know that it can deal 
with this token type? So endpoint has to try to lookup token  to determine if 
it can maybe find out something about the token? Can the one use the 
authorization code or does one have to get a token first?

Can I send a encrypted token and expect a proper response ? What about a Proof 
of Possession Token?

Introspection Response
What is active mean ? Is this up to the server to determine ?
scope OPTIONAL, is this the scope in the token or is this the scope that the 
introspection endpoint sources may have ? It's unclear if all these return 
values are from the token or from the introspection endpoint sources ?
What error codes/conditions are there? Just the 400  (bad request)?
Can the endpoint return a encrypted response ?
What about PII such as user_id, aud ?
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Notes from 2nd OAuth Authentication Conference Call

[Anthony Nadalin]

Same here

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
Sent: Thursday, October 16, 2014 10:17 AM
To: Hannes Tschofenig; oauth@ietf.org
Subject: Re: [OAUTH-WG] Notes from 2nd OAuth  Authentication Conference Call

For what it's worth, I was on the call too - until I and Brian left to join the 
telechat for the OAuth assertions drafts.

-- Mike

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Thursday, October 16, 2014 9:55 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Notes from 2nd OAuth  Authentication Conference Call

Participants:

 * Brian Campbell
 * John Bradley
 * Derek Atkins
 * Phil Hunt
 * William Kim
 * Josh Mandel
 * Hannes Tschofenig


Notes:

Justin distributed a draft writeup and explained the reasoning behind it. The 
intended purpose is to put the write-up (after enough review) on oauth.net. See 
attachments. Justin solicited feedback from the conference call participants 
and from the working group.

One discussion item was specifically related to the concept of audience 
restrictions, which comes in two flavours: (a) restriction of the access token 
regarding the resource server and (b) restriction of the id token regarding the 
client. Obviously, it is necessary to have both of these audience restrictions 
in place and to actually check them.

The group then went into a discussion about the use of pseudonyms in 
authentication and the problems deployments ran into when they used pseudonyms 
together with a wide range of attributes that identified users nevertheless. 
Phil suggested to produce a write-up about this topic.

Finally, the group started a discussion about potential actions for the OAuth 
working groups. Two activities were mentioned, namely to produce an IETF draft 
of the write-up Justin has prepared as a formal response to the problems with 
authentication using OAuth and, as a second topic, potential re-chartering of 
the OAuth working group to work on some solutions in this area. Hannes 
suggested to postpone these discussions and to first finish the write-up Justin 
had distributed.

Ciao
Hannes  Derek
___
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] Dynamic Client Registration Management Protocol: Next Steps?

[Anthony Nadalin]

Is experimental the correct classification? Maybe informational is more 
appropriate as both of these were discussed. 

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Wednesday, September 10, 2014 4:50 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next Steps?

Hi all,

in response to the discussions at the last IETF meeting the authors of the 
Dynamic Client Registration Management Protocol
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-05 have changed 
the document type to Experimental.

We need to make a decision about the next steps for the document and we see the 
following options:

a) Publish it as an experimental RFC

b) Remove it from the working group and ask an AD to shepherd it

c) Remove it from the working group and let the authors publish it via the 
independent submission track.

In any case it would be nice to let folks play around with it and then, after 
some time, come back to determine whether there is enough interest to produce a 
standard.

Please let us know what you think!

Ciao
Hannes  Derek



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

Re: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next Steps?

[Anthony Nadalin]

I don't see it that way as the guidelines not clear and we should revisit this 
since there was no conclusion in Toronto. 

-Original Message-
From: Richer, Justin P. [mailto:jric...@mitre.org] 
Sent: Thursday, September 11, 2014 8:01 AM
To: Anthony Nadalin
Cc: Hannes Tschofenig; oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next 
Steps?

According to the guidelines here:

https://www.ietf.org/iesg/informational-vs-experimental.html

And the discussion in Toronto, it's clearly experimental.

 -- Justin

On Sep 11, 2014, at 10:36 AM, Anthony Nadalin tony...@microsoft.com wrote:

 Is experimental the correct classification? Maybe informational is more 
 appropriate as both of these were discussed. 
 
 -Original Message-
 From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
 Sent: Wednesday, September 10, 2014 4:50 PM
 To: oauth@ietf.org
 Subject: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next 
 Steps?
 
 Hi all,
 
 in response to the discussions at the last IETF meeting the authors of the 
 Dynamic Client Registration Management Protocol
 http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-05 have 
 changed the document type to Experimental.
 
 We need to make a decision about the next steps for the document and we see 
 the following options:
 
 a) Publish it as an experimental RFC
 
 b) Remove it from the working group and ask an AD to shepherd it
 
 c) Remove it from the working group and let the authors publish it via the 
 independent submission track.
 
 In any case it would be nice to let folks play around with it and then, after 
 some time, come back to determine whether there is enough interest to produce 
 a standard.
 
 Please let us know what you think!
 
 Ciao
 Hannes  Derek
 
 
 
 ___
 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 Authentication: What can go wrong?

[Anthony Nadalin]

Add me

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Thursday, September 11, 2014 3:30 PM
To: oauth@ietf.org
Cc: Derek Atkins
Subject: [OAUTH-WG] OAuth  Authentication: What can go wrong?

Hi all,

at the last IETF meeting Mike gave a presentation about the 
draft-hunt-oauth-v2-user-a4c and the conclusion following the discussion was to 
discuss the problems that happen when OAuth gets used for authentication.

The goal of this effort is to document the problems in an informational 
document.

Conference calls could start in about 2 weeks and we would like to know who 
would be interested to participate in such a discussion.

Please drop us a private mail so that we can find suitable dates/times.

Ciao
Hannes  Derek

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

Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth 2.0 Token Exchange as an OAuth Working Group Item

[Anthony Nadalin]

I read the draft and just don’t get it, it overloads some of the basic 
semantics, I’m not quite sure you get the concept of token exchange, has what 
you described been deployed ? or even built ?

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Monday, August 11, 2014 7:42 AM
To: Mike Jones
Cc: oauth-cha...@tools.ietf.org; oauth@ietf.org
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth 2.0 Token 
Exchange as an OAuth Working Group Item

I'd be okay with that as a way forward. Frankly, of course, I'd prefer to see 
draft-campbell-oauth-sts as the starting point with Mike and the other 
draft-jones-oauth-token-exchange authors added as co-authors. Regardless, there 
are elements from both that likely need to end up in the final work so a 
consolidation of authors and concepts makes sense.
And yes, there are lots of details that the working group will need to decide 
on going forward that we shouldn't get hung up on right now. Though I believe 
that deciding if the token endpoint is used for general token exchange is an 
important philosophical question that should be answered first. If the token 
endpoint is to be used, I strongly belie that this token exchange should 
leverage and work within the constructs provided and defined by OAuth. That's 
the direction I took with draft-campbell-oauth-sts and yes that involves 
overloading the access_token response parameter with something that's not 
always strictly an access token. The existing token endpoint request/response 
are already rather close to what one might expect in an STS type exchange. I 
find there's a nice elegant simplicity to it but I also see where that 
discomfort might come from. If there's consensus to not use/overload the 
existing stuff, I think it'd be much more appropriate to define a new endpoint. 
A lot of syntactic stuff likely falls out from that decision.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth Token Introspection as an OAuth Working Group Item

[Anthony Nadalin]

John this is for the people that did not hum  at the face to face and not just 
for the people not  at the face to face.

Sent from my Windows Phone

From: John Bradleymailto:ve7...@ve7jtb.com
Sent: ‎7/‎30/‎2014 7:20 AM
To: Sergey Beryozkinmailto:sberyoz...@gmail.com
Cc: oauth@ietf.orgmailto:oauth@ietf.org
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth Token 
Introspection as an OAuth Working Group Item

No worries.

Some of the people in the F2F piling on with discussion derailed  Hannes 
original question.
  during the IETF #90 OAuth WG meeting, there was strong
consensus in
adopting the OAuth Token Introspection
(draft-richer-oauth-introspection-06.txt) specification as an
OAuth WG
work item.

We would now like to verify the outcome of this call for
adoption on the
OAuth WG mailing list. Here is the link to the document:
http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/

If you did not hum at the IETF 90 OAuth WG meeting, and have
an opinion
as to the suitability of adopting this document as a WG work
item,
please send mail to the OAuth WG list indicating your opinion
(Yes/No).

The confirmation call for adoption will last until August 10,
2014.  If
you have issues/edits/comments on the document, please send these
comments along to the list in your response to this Call for
Adoption.

People not in the room commenting and asking questions is expected.   People 
who expressed opinions in the room should avoid double counting by making it 
clear they hummed in the room, as our AD may not know everyone's face and name.

I don't know how I became the process monitor.   Normally I am the trouble 
maker.

I believe what passed for consensus in the room was that this ork is in scope 
for the WG and this document can serve as a starting point, but that there are 
things that need to be added.

I think Phil would like a use case document to flesh out peoples understanding. 
 Others who have been working on this longer are hesitant that doing a use case 
document without adopting Justin's document as a starting point, will stall the 
process.

We can however adopt Justin's doc and in parallel add a use case section as 
part of the doc or as a separate doc.

So if you were not in the F2F hum you need to express an opinion on if 
draft-richer-oauth-introspection-06.txt should be adopted by the WG item.

John B.
(PS I was in the room and hummed in favour of adopting this as a work item)

On Jul 30, 2014, at 8:05 AM, Sergey Beryozkin sberyoz...@gmail.com wrote:

 Hi John
 On 30/07/14 14:59, John Bradley wrote:
 No,  that those of us who we're fallowing the instructions not to comment if 
 our hum was recorded in the room, should not hold back given the nature of 
 the thread has changed.

 It was also an indication to the char that the original intent of the thread 
 to judge consensus is impacted by some people who previously hummed piling 
 on the thread.

 I think I understand, thanks for the clarifications, though it appears to be 
 more subtle to me that various OAuth2 technical ambiguities :-)
 I am more than fine with discussion.  It probably should have been a 
 different thread though.

 Thanks, sorry for the noise anyway

 Sergey
 John B.
 Sent from my iPhone

 On Jul 30, 2014, at 7:51 AM, Sergey Beryozkin sberyoz...@gmail.com wrote:

 On 30/07/14 14:42, John Bradley wrote:
 This request for only those not at the F2F to add to the hum has gone a 
 bit off the rails.
 Meaning you see too much feedback, is it bad, even if some of it may be off 
 topic ?
 For those not in the room there was discussion that the draft needed a 
 method to deal with:
 - Multiple AS
 - Supporting the PoP specs
 - stopping clients or other interceptors of the token from introspecting 
 it.

 Justin stated that his implementation already had a number of those 
 features.

 I offered to help get those into the spec as part of my support for making 
 this a WG item.

 Yes if AS and RS are monolithic and there is only one software vendor, 
 then this is not needed.
 Why not ? What is wrong with standardizing an introspection process which 
 even RS  AS from the same vendor may want to use as opposed to every 
 vendor inventing its own protocol ?

 This is why I thought focusing on the RS to 3rd party only diverts from the 
 idea which I 'read' in the thread (may be I'm wrong), i.e, standardizing on 
 the RS-to-AS communication, which may not have been considered,

 Cheers, Sergey


 On the other hand there is evidence that is not the case.

 John B.


 Sent from my iPad

 On Jul 30, 2014, at 3:45 AM, Sergey Beryozkin sberyoz...@gmail.com 
 wrote:

 +1.

 I've understood from what Justin said the idea is to introduce a standard 
 way for RS to communicate to AS about the tokens issued by the AS. I 
 think it is a 

Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth Token Introspection as an OAuth Working Group Item

[Anthony Nadalin]

I think we need management APIs now to manage the new endpoint, but seriously 
this introspection proposal has privacy issues, to avoid these I would encrypt 
the tokens and then this would be a useless endpoint, also this has issues with 
symmetric POP tokens, but maybe this was only designed to work on bearer tokens.



From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer
Sent: Tuesday, July 29, 2014 6:08 PM
To: Phil Hunt; Thomas Broyer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth Token 
Introspection as an OAuth Working Group Item

So you want a service where the RS can call an HTTP endpoint to see if the 
token is alive or not? That sounds like an awesome idea! Very useful for a 
variety of use cases that people have already mentioned on that list. Maybe 
that service should respond in JSON with, say, { active: true } if it's still 
valid. That's a great start, and that should obviously be MTI.

But while we're there, we probably want to know what else the token is for, 
since this service will probably know that, so let's add in the scope and 
client_id and whatever other meta-information we have about the token. If 
this endpoint doesn't have that information? Well then, I guess it can't return 
it. So we need to make sure to be flexible about that while we define a common 
core set of semantics. Flexibility like that is very powerful and could be used 
in a variety of protocols and deployments across domains and vendors.

You know, this idea is sounding better and better. In fact, I'll do you one 
better. I think this is such a fantastic idea that I wrote it all down in RFC 
format:

http://tools.ietf.org/html/draft-richer-oauth-introspection-06

Glad to have you on board, Phil.

 -- Justin

On 7/29/2014 9:02 PM, Phil Hunt wrote:
I think one alternative to an introspection service is a revocation status 
service.

But it is often not needed if token lifetimes are small (minutes / session 
life) compared to the refresh token which might last much longer.

Again having info on the case helps explain the requirements of your case and 
we can tell what the best pattern is.

Phil

On Jul 29, 2014, at 17:55, Thomas Broyer 
t.bro...@gmail.commailto:t.bro...@gmail.com wrote:

Try it where? When you're the RS trying to determine whether you should accept 
the token or reject it?
Le 30 juil. 2014 02:49, Mike Jones 
michael.jo...@microsoft.commailto:michael.jo...@microsoft.com a écrit :
Yes, but that’s the simplest thing to determine – try the token and see whether 
it works or not.

From: Thomas Broyer [mailto:t.bro...@gmail.commailto:t.bro...@gmail.com]
Sent: Tuesday, July 29, 2014 5:43 PM
To: Mike Jones
Cc: oauth@ietf.orgmailto:oauth@ietf.org; George Fletcher; Phil Hunt
Subject: RE: [OAUTH-WG] Confirmation: Call for Adoption of OAuth Token 
Introspection as an OAuth Working Group Item


Decoding a token with a specific format wouldn't tell you whether the token is 
still live: it could have been revoked before its expiration.
Le 30 juil. 2014 02:16, Mike Jones 
michael.jo...@microsoft.commailto:michael.jo...@microsoft.com a écrit :
Did you consider standardizing the access token format within that deployment 
so all the parties that needed to could understand it, rather requiring an 
extra round trip to an introspection endpoint so as to be able to understand 
things about it?

I realize that might or might not be practical in some cases, but I haven’t 
heard that alternative discussed, so I thought I’d bring it up.

I also second Phil’s comment that it would be good to understand the use cases 
that this is intended to solve before embarking on a particular solution path.

-- Mike

From: OAuth [mailto:oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org] On 
Behalf Of George Fletcher
Sent: Tuesday, July 29, 2014 3:25 PM
To: Phil Hunt; Thomas Broyer
Cc: oauth@ietf.orgmailto:oauth@ietf.org
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth Token 
Introspection as an OAuth Working Group Item

We also have a use case where the AS is provided by a partner and the RS is 
provided by AOL. Being able to have a standardized way of validating and 
getting data about the token from the AS would make our implementation much 
simpler as we can use the same mechanism for all Authorization Servers and not 
have to implement one off solutions for each AS.

Thanks,
George
On 7/28/14, 8:11 PM, Phil Hunt wrote:
Could we have some discussion on the interop cases?

Is it driven by scenarios where AS and resource are separate domains? Or may 
this be only of interest to specific protocols like UMA?

From a technique principle, the draft is important and sound. I am just not 
there yet on the reasons for an interoperable standard.

Phil

On Jul 28, 2014, at 17:00, Thomas Broyer 
t.bro...@gmail.commailto:t.bro...@gmail.com wrote:
Yes. This spec is of special interest to the platform we're building for 

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt

[Anthony Nadalin]

OMG, how can you say that when the Dynamkc Reg does the same thing (duplicates) 
but that is OK to do

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, July 24, 2014 10:22 AM
To: John Bradley
Cc: oauth@ietf.org list
Subject: Re: [OAUTH-WG] New Version Notification for 
draft-hunt-oauth-v2-user-a4c-05.txt

I'm sorry to miss what will likely be a very engaging meeting today.

The premise that some developers are using OAuth in a insecure way to do 
authentication is something we can probably all agree on.

It doesn't necessarily follow from that premise, however, that the solution is 
yet another spec which either duplicates some subset of OpenID Connect (in a 
different SDO) or forks how to do SSO/authentication using OAuth.

On Thu, Jul 24, 2014 at 7:25 AM, John Bradley 
ve7...@ve7jtb.commailto:ve7...@ve7jtb.com wrote:
I am not against discussion in the WG.

I happen to agree with Phil's fundamental premise that some developers are 
using OAuth in a insecure way to do authentication.

That raises the question of how to best educate them, and or address technical 
barriers.

It is on the second point that people's opinions seem to divide.

Some people thing that if we have a OAuth flow that eliminates the access token 
(primarily to avoid asking for consent as I understand it) and just return a 
id_token from the token endpoint that can be done in a spec short enough to het 
people to read.   The subtext of this is that the Connect specification is too 
large that it scare people,  and they don't find the spec in the first place 
because it is not a RFC.

An other common possession is that if you don't want to prompt the user for 
consent then don't ask for scopes.  Twisting the OAuth spec to not return an 
access token is not OAuth,  yes you could use a different endpoint rather than 
the token endpoint, but that is not OAuth.   Connect was careful not to break 
the OAuth spec.As long as you are willing to take a access token with no 
scopes (the client needs to understand that there are no attributes one way or 
another anyway or it will break) then you don't need to change OAuth.   You can 
publish a profile of connect that satisfies the use case.

I think Mike has largely done that but it might be better being less stingy on 
references back to the larger spec.

The questions are do we modify OAuth to not return an access token, and if so 
how,  and if we do is it still OAuth.

The other largely separable question is do we create confusion in the market 
and slow the the adoption of identity federation on top of OAuth, or find a way 
to make this look like a positive alignment of interests around a subset of 
Connect.

There are a number of options.
1: We can do a profile in the OIDF and publish it as a IETF document.   Perhaps 
the cleanest from an IPR point of view.
2:We can do a profile in the OAuth WG referencing connect.
3:We can do a AD sponsored profile that is not in the OAuth WG.
4:We can do a small spec in OAuth to add response_type to the token endpoint.  
in combination with 1, 2, or 3

I agree that stoping developers doing insecure things needs to be addressed 
somehow.
I am not personally convinced that Oauth without access tokens is sensible.

Looking forward to the meeting:)

John B.

On Jul 24, 2014, at 6:52 AM, Brian Campbell 
bcampb...@pingidentity.commailto:bcampb...@pingidentity.com wrote:


I'd note that the reaction at the conference to Ian's statement was 
overwhelmingly positive. There was a wide range of industry people here - 
implementers, practitioners, deployers, strategists, etc. - and it seems pretty 
clear that the rough consensus of the industry at large is that a4c is not 
wanted or needed.

On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura 
sakim...@gmail.commailto:sakim...@gmail.com wrote:
And here is a quote from Ian's blog.

And although the authentication wheel is round, that doesn’t mean it isn’t 
without its lumps. First, we do see some reinventing the wheel just to reinvent 
the wheel. OAuth A4C is simply not a fruitful activity and should be put down.

(Source) 
http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musings-on-identity-standards-part-1.html

2014-07-23 16:53 GMT-04:00 John Bradley 
ve7...@ve7jtb.commailto:ve7...@ve7jtb.com:

I thought I did post this to the list.

I guess I hit the wrong reply on my phone.

John B.
Sent from my iPhone

On Jul 23, 2014, at 4:50 PM, 
tors...@lodderstedt.netmailto:tors...@lodderstedt.net wrote:

we are two, at least :-)

Why didn't you post this on the list?

When will be be arriving?

Am 23.07.2014 16:39, schrieb John Bradley:
Ian Glazer mentioned this in his keynote at CIS yesterday.

His advice was please stop,  we are creating confusion and uncertainty.

We are becoming our own wort enemy. ( my view though Ian may share it)

Returning just an id_ token from the token endpoint has little real value.

Something really useful to do would be sorting out 

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt

[Anthony Nadalin]

Oh yea, real different, give me a freaking break

From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Thursday, July 24, 2014 6:31 PM
To: Anthony Nadalin
Cc: John Bradley; oauth@ietf.org list
Subject: Re: [OAUTH-WG] New Version Notification for 
draft-hunt-oauth-v2-user-a4c-05.txt

The situations are rather different.

On Thu, Jul 24, 2014 at 11:25 AM, Anthony Nadalin 
tony...@microsoft.commailto:tony...@microsoft.com wrote:
OMG, how can you say that when the Dynamkc Reg does the same thing (duplicates) 
but that is OK to do

From: OAuth [mailto:oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org] On 
Behalf Of Brian Campbell
Sent: Thursday, July 24, 2014 10:22 AM

To: John Bradley
Cc: oauth@ietf.orgmailto:oauth@ietf.org list
Subject: Re: [OAUTH-WG] New Version Notification for 
draft-hunt-oauth-v2-user-a4c-05.txt

I'm sorry to miss what will likely be a very engaging meeting today.

The premise that some developers are using OAuth in a insecure way to do 
authentication is something we can probably all agree on.

It doesn't necessarily follow from that premise, however, that the solution is 
yet another spec which either duplicates some subset of OpenID Connect (in a 
different SDO) or forks how to do SSO/authentication using OAuth.

On Thu, Jul 24, 2014 at 7:25 AM, John Bradley 
ve7...@ve7jtb.commailto:ve7...@ve7jtb.com wrote:
I am not against discussion in the WG.

I happen to agree with Phil's fundamental premise that some developers are 
using OAuth in a insecure way to do authentication.

That raises the question of how to best educate them, and or address technical 
barriers.

It is on the second point that people's opinions seem to divide.

Some people thing that if we have a OAuth flow that eliminates the access token 
(primarily to avoid asking for consent as I understand it) and just return a 
id_token from the token endpoint that can be done in a spec short enough to het 
people to read.   The subtext of this is that the Connect specification is too 
large that it scare people,  and they don't find the spec in the first place 
because it is not a RFC.

An other common possession is that if you don't want to prompt the user for 
consent then don't ask for scopes.  Twisting the OAuth spec to not return an 
access token is not OAuth,  yes you could use a different endpoint rather than 
the token endpoint, but that is not OAuth.   Connect was careful not to break 
the OAuth spec.As long as you are willing to take a access token with no 
scopes (the client needs to understand that there are no attributes one way or 
another anyway or it will break) then you don't need to change OAuth.   You can 
publish a profile of connect that satisfies the use case.

I think Mike has largely done that but it might be better being less stingy on 
references back to the larger spec.

The questions are do we modify OAuth to not return an access token, and if so 
how,  and if we do is it still OAuth.

The other largely separable question is do we create confusion in the market 
and slow the the adoption of identity federation on top of OAuth, or find a way 
to make this look like a positive alignment of interests around a subset of 
Connect.

There are a number of options.
1: We can do a profile in the OIDF and publish it as a IETF document.   Perhaps 
the cleanest from an IPR point of view.
2:We can do a profile in the OAuth WG referencing connect.
3:We can do a AD sponsored profile that is not in the OAuth WG.
4:We can do a small spec in OAuth to add response_type to the token endpoint.  
in combination with 1, 2, or 3

I agree that stoping developers doing insecure things needs to be addressed 
somehow.
I am not personally convinced that Oauth without access tokens is sensible.

Looking forward to the meeting:)

John B.

On Jul 24, 2014, at 6:52 AM, Brian Campbell 
bcampb...@pingidentity.commailto:bcampb...@pingidentity.com wrote:

I'd note that the reaction at the conference to Ian's statement was 
overwhelmingly positive. There was a wide range of industry people here - 
implementers, practitioners, deployers, strategists, etc. - and it seems pretty 
clear that the rough consensus of the industry at large is that a4c is not 
wanted or needed.

On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura 
sakim...@gmail.commailto:sakim...@gmail.com wrote:
And here is a quote from Ian's blog.

And although the authentication wheel is round, that doesn’t mean it isn’t 
without its lumps. First, we do see some reinventing the wheel just to reinvent 
the wheel. OAuth A4C is simply not a fruitful activity and should be put down.

(Source) 
http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musings-on-identity-standards-part-1.html

2014-07-23 16:53 GMT-04:00 John Bradley 
ve7...@ve7jtb.commailto:ve7...@ve7jtb.com:

I thought I did post this to the list.

I guess I hit the wrong reply on my phone.

John B.
Sent from my iPhone

On Jul 23, 2014, at 4:50 PM, 
tors...@lodderstedt.netmailto:tors

Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

[Anthony Nadalin]

The explanation of on-behalf-Of and ActAs are correct in the document as 
defined by WS-Trust, this may not be your desire or understanding but that is 
how WS-Trust implementations should work

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, July 3, 2014 11:44 AM
To: Vladimir Dzhuvinov
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

FWIW, I am very interested in the general concept of a lightweight or OAuth 
based token exchange mechanism. However, despite some distaste for the 
protocol, our existing WS-Trust functionality has proven to be good enough 
for most use-cases, which seems to prevent work on token exchange from getting 
any real priority.
I have a few thoughts on 
http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 which I've been 
meaning to write down but haven't yet, so this seems like as good a time as any.
I would really like to see a simpler request model that doesn't require the 
request to be JWT encoded.
The draft mentions the potential confusion around On-Behalf-Of vs. 
Impersonation Semantics. And it is confusing (to me anyway). In fact, the use 
of Act-As and On-Behalf-Of seem to be reversed from how they are defined in 
WS-Trusthttp://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html (this MS 
FAQhttp://msdn.microsoft.com/en-us/library/ee748487.aspx has less confusing 
wording). They should probably be aligned with that prior work to avoid further 
confusion. Or maybe making a clean break and introducing new terms would be 
better.
I don't think the security_token_request grant type value is strictly legal per 
RFC 6749. The ABNF at http://tools.ietf.org/html/rfc6749#appendix-A.10 would 
allow it but according to http://tools.ietf.org/html/rfc6749#section-4.5 
extension grants need an absolute URI as the grant type value (there's no grant 
type registry so the URI is the only means of preventing collision).






On Fri, Jun 27, 2014 at 6:07 AM, Vladimir Dzhuvinov 
vladi...@connect2id.commailto:vladi...@connect2id.com wrote:
Has anyone implemented the OAuth 2.0 Token exchange draft, in particular
the on-behalf-of semantics? We've got a use case for that and I'm
curious if someone has used it in practice.

http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00

Thanks,

Vladimir
--
Vladimir Dzhuvinov vladi...@connect2id.commailto:vladi...@connect2id.com
Connect2id Ltd.

___
OAuth mailing list
OAuth@ietf.orgmailto: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] draft-jones-oauth-token-exchange-00

[Anthony Nadalin]

I’m lost, the terms defined in the oauth token-exchange draft are the same 
terms defined in ws-trust and have the same definitions

From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Thursday, July 3, 2014 12:02 PM
To: Anthony Nadalin
Cc: Vladimir Dzhuvinov; oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

And I was suggesting that OAuth token exchange align with the WS-Trust 
definitions or maybe even define totally new terms. But not use the same terms 
to mean different things.

On Thu, Jul 3, 2014 at 12:55 PM, Anthony Nadalin 
tony...@microsoft.commailto:tony...@microsoft.com wrote:
The explanation of on-behalf-Of and ActAs are correct in the document as 
defined by WS-Trust, this may not be your desire or understanding but that is 
how WS-Trust implementations should work

From: OAuth [mailto:oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org] On 
Behalf Of Brian Campbell
Sent: Thursday, July 3, 2014 11:44 AM
To: Vladimir Dzhuvinov
Cc: oauth@ietf.orgmailto:oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

FWIW, I am very interested in the general concept of a lightweight or OAuth 
based token exchange mechanism. However, despite some distaste for the 
protocol, our existing WS-Trust functionality has proven to be good enough 
for most use-cases, which seems to prevent work on token exchange from getting 
any real priority.
I have a few thoughts on 
http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 which I've been 
meaning to write down but haven't yet, so this seems like as good a time as any.
I would really like to see a simpler request model that doesn't require the 
request to be JWT encoded.
The draft mentions the potential confusion around On-Behalf-Of vs. 
Impersonation Semantics. And it is confusing (to me anyway). In fact, the use 
of Act-As and On-Behalf-Of seem to be reversed from how they are defined in 
WS-Trusthttp://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html (this MS 
FAQhttp://msdn.microsoft.com/en-us/library/ee748487.aspx has less confusing 
wording). They should probably be aligned with that prior work to avoid further 
confusion. Or maybe making a clean break and introducing new terms would be 
better.
I don't think the security_token_request grant type value is strictly legal per 
RFC 6749. The ABNF at http://tools.ietf.org/html/rfc6749#appendix-A.10 would 
allow it but according to http://tools.ietf.org/html/rfc6749#section-4.5 
extension grants need an absolute URI as the grant type value (there's no grant 
type registry so the URI is the only means of preventing collision).





On Fri, Jun 27, 2014 at 6:07 AM, Vladimir Dzhuvinov 
vladi...@connect2id.commailto:vladi...@connect2id.com wrote:
Has anyone implemented the OAuth 2.0 Token exchange draft, in particular
the on-behalf-of semantics? We've got a use case for that and I'm
curious if someone has used it in practice.

http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00

Thanks,

Vladimir
--
Vladimir Dzhuvinov vladi...@connect2id.commailto:vladi...@connect2id.com
Connect2id Ltd.

___
OAuth mailing list
OAuth@ietf.orgmailto: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] draft-jones-oauth-token-exchange-00

[Anthony Nadalin]

ActAs the returned token is expected to be represented by the identity 
described by this parameter
OnBehalfOf the request is being made by the identity described by this parameter

These terms have been pretty clearly defined in the WS specifications, I don't 
understand the confusion. If section 1.3 is confusing, I'm OK with dropping this

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Thursday, July 3, 2014 2:44 PM
To: Phil Hunt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

I pointed out a problem with the non normative text in sec 1.3 to Mike off list 
quite a while go.

1.3http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00#section-1.3.
  On-Behalf-Of vs. Impersonation Semantics





   When principal A acts on behalf of principal B, A is given all the

   rights that B has within some defined rights context.  Whereas, with

   on-behalf-of semantics, principal A still has its own identity

   separate from B and it is explicitly understood that while B may have

   delegated its rights to A, any actions taken are being taken by A and

   not B. In a sense, A is an agent for B.

   On-behalf-of semantics are therefore different than impersonation

   semantics, with which it is sometimes confused.  When principal A

   impersonates principal B, then in so far as any entity receiving

   Claims is concerned, they are actually dealing with B. It is true

   that some members of the identity system might have awareness that

   impersonation is going on but it is not a requirement.  For all

   intents and purposes, when A is acting for B, A is B.

OnBehalfOf  indicates that the requestor is making the request on behalf of 
another. and returns a security token to the requestor that contains a single 
set of claims.

ActAs provides a security token/ assertion about subject A in a request from 
Requester B and the response is a composite token that has Requester B as the 
subject but also includes claims about subject A.

See MS FAQ to clarify this  popular question 
http://msdn.microsoft.com/en-us/library/ee748487.aspx

I think this is what Brian was trying to get at.

If we can't all agree on the semantics of OnBehalfOf (It has been around for a 
long time) then we have a problem and should pick different terms.

The normative text is correct, however sec 2.2 adds an optional actor claim 
to the initial JWT that is to be presented as the value of  on_behalf_of in the 
request.  That is an addition to the WS-Trust text and took me several reads to 
understand that it is not a element in the JWT response.

I offered to help with the spec as I think it is useful.  The semantics are 
tricky for people to understand so I was not all that concerned that the first 
draft was not perfect.

I suspect some concrete examples will help.

John B.

On Jul 3, 2014, at 3:51 PM, Phil Hunt 
phil.h...@oracle.commailto:phil.h...@oracle.com wrote:


I suspect it lines up. But Brian's point may still be relevant. There is *long* 
standing confusion of the terms (because many of have different english 
interpretation than WS-Trust). Might be time for new terms?

Impersonate (or even personate) vs. delegate ?

Those terms differentiate between impersonating a whole person vs. having 
delegate or scoped authority to act for someone.

Sorry if this is an old discussion.

Phil

@independentid
www.independentid.comhttp://www.independentid.com/
phil.h...@oracle.commailto:phil.h...@oracle.com



On Jul 3, 2014, at 12:20 PM, Mike Jones 
michael.jo...@microsoft.commailto:michael.jo...@microsoft.com wrote:


I'm lost too, as when I wrote this, I explicitly modelled it after WS-Trust.  
If there's a concrete discrepancy you can point out, that would be great.

FYI, I do plan to refresh this draft too allow for a more flexible trust model 
shortly.

-- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
Sent: Thursday, July 03, 2014 12:04 PM
To: Brian Campbell
Cc: oauth@ietf.orgmailto:oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

I'm lost, the terms defined in the oauth token-exchange draft are the same 
terms defined in ws-trust and have the same definitions

From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Thursday, July 3, 2014 12:02 PM
To: Anthony Nadalin
Cc: Vladimir Dzhuvinov; oauth@ietf.orgmailto:oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

And I was suggesting that OAuth token exchange align with the WS-Trust 
definitions or maybe even define totally new terms. But not use the same terms 
to mean different things.

On Thu, Jul 3, 2014 at 12:55 PM, Anthony Nadalin 
tony...@microsoft.commailto:tony...@microsoft.com wrote:
The explanation of on-behalf-Of and ActAs are correct in the document as 
defined by WS-Trust, this may not be your desire or understanding but that is 
how WS-Trust

Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

[Anthony Nadalin]

It’s great but some ways but also very limiting if you are counting on certain 
requirements to be represented in the access token

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt
Sent: Thursday, June 5, 2014 12:40 PM
To: Bill Mills
Cc: Phil Hunt; oauth@ietf.org
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

+1

the access token is opaque to the client. That's great! Let's keep it that way.

Am 05.06.2014 um 21:20 schrieb Bill Mills 
wmills_92...@yahoo.commailto:wmills_92...@yahoo.com:
Can't agree more with the peril of overloading auth information into an access 
token.

On Thursday, June 5, 2014 11:05 AM, Mike Jones 
michael.jo...@microsoft.commailto:michael.jo...@microsoft.com wrote:

Hannes, the Access Token and ID Token do quite different things and have 
different structures and properties.  The Access Token is an opaque value that 
grants access to resources.  An ID Token is a non-opaque JWT security token 
that makes claims about the authentication that occurred.  You can have one 
without the other or you can have both, depending upon the use case.  Thus, 
trying to move information between them would be problematic in several regards.

Also, trying to overload the Access Token to convey authentication information 
has been demonstrated in practice to be fraught with peril, and has resulted in 
some of the most prominent security breaches related to the misuse of OAuth.

-- Mike

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org] On 
Behalf Of Phil Hunt
Sent: Thursday, June 05, 2014 8:54 AM
To: Hannes Tschofenig
Cc: oauth@ietf.orgmailto:oauth@ietf.org
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

You are correct. Just adding to access token would make a lot of devs happy and 
that certainly should be discussed.

Two requirements issues:

1. A key use case is passing auth ctx only. An access token means asking for 
consent to access something. This causes many sites to loose new users. Authen 
only can be implicit consent.

2.  Compatibility with OpenId ID Token and flows.

3. There is a need to support re-auth and MFA/LOA negotiation. Eg web site 
would like to obtain a higher level of assurance for a higher risk action.

The non-tech requirement is the soln must be received by client and service 
provider developers as easy to implement in addition to 6749 or even OAuth 
1.1a. I mention it because devs feel this should be trivial.  Your suggestion 
of adding to access token certainly fits this.

Phil

 On Jun 5, 2014, at 0:44, Hannes Tschofenig 
 hannes.tschofe...@gmx.netmailto:hannes.tschofe...@gmx.net wrote:

 Hi Phil,

 thanks for producing this document write-up. I have a somewhat basic
 question regarding the document.

 The id token contains the following mandatory information:
 - sis: issuer
 - sub: subject
 - aud: audience
 - iat: issued at
 - exp: expiry
 - auth_time: time when the end user was authenticated

 An access token (when encoded as a JWT) may contain all these fields
 except the auth_time (since auth_time is not defined in the JWT spec).

 Given that your proposal actually does not define the authentication
 protocol to be used between the resource owner/end user and the
 authorisation server I am wondering whether it would be possible to
 just add the auth_time parameter (and maybe some of the optional
 parameters) to the access token. Then, you can skip the id token.

 How do I come up with that question? In Kerberos, for example, the
 above-listed information is carried within a single container (within
 the ticket) and so I am curious to hear why we have to send the
 information twice in OAuth (once in the access token, when the info is
 passed per value, and again via the id token).

 Maybe I missing something important here.

 Ciao
 Hannes



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


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

___
OAuth mailing list
OAuth@ietf.orgmailto: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] Question regarding draft-hunt-oauth-v2-user-a4c

[Anthony Nadalin]

Delegation

From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Thursday, June 5, 2014 12:45 PM
To: Anthony Nadalin
Cc: Bill Mills; Phil Hunt; oauth@ietf.org
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

Examples?

Am 05.06.2014 um 21:42 schrieb Anthony Nadalin 
tony...@microsoft.commailto:tony...@microsoft.com:
It’s great but some ways but also very limiting if you are counting on certain 
requirements to be represented in the access token

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt
Sent: Thursday, June 5, 2014 12:40 PM
To: Bill Mills
Cc: Phil Hunt; oauth@ietf.orgmailto:oauth@ietf.org
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

+1

the access token is opaque to the client. That's great! Let's keep it that way.

Am 05.06.2014 um 21:20 schrieb Bill Mills 
wmills_92...@yahoo.commailto:wmills_92...@yahoo.com:
Can't agree more with the peril of overloading auth information into an access 
token.

On Thursday, June 5, 2014 11:05 AM, Mike Jones 
michael.jo...@microsoft.commailto:michael.jo...@microsoft.com wrote:

Hannes, the Access Token and ID Token do quite different things and have 
different structures and properties.  The Access Token is an opaque value that 
grants access to resources.  An ID Token is a non-opaque JWT security token 
that makes claims about the authentication that occurred.  You can have one 
without the other or you can have both, depending upon the use case.  Thus, 
trying to move information between them would be problematic in several regards.

Also, trying to overload the Access Token to convey authentication information 
has been demonstrated in practice to be fraught with peril, and has resulted in 
some of the most prominent security breaches related to the misuse of OAuth.

-- Mike

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org] On 
Behalf Of Phil Hunt
Sent: Thursday, June 05, 2014 8:54 AM
To: Hannes Tschofenig
Cc: oauth@ietf.orgmailto:oauth@ietf.org
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

You are correct. Just adding to access token would make a lot of devs happy and 
that certainly should be discussed.

Two requirements issues:

1. A key use case is passing auth ctx only. An access token means asking for 
consent to access something. This causes many sites to loose new users. Authen 
only can be implicit consent.

2.  Compatibility with OpenId ID Token and flows.

3. There is a need to support re-auth and MFA/LOA negotiation. Eg web site 
would like to obtain a higher level of assurance for a higher risk action.

The non-tech requirement is the soln must be received by client and service 
provider developers as easy to implement in addition to 6749 or even OAuth 
1.1a. I mention it because devs feel this should be trivial.  Your suggestion 
of adding to access token certainly fits this.

Phil

 On Jun 5, 2014, at 0:44, Hannes Tschofenig 
 hannes.tschofe...@gmx.netmailto:hannes.tschofe...@gmx.net wrote:

 Hi Phil,

 thanks for producing this document write-up. I have a somewhat basic
 question regarding the document.

 The id token contains the following mandatory information:
 - sis: issuer
 - sub: subject
 - aud: audience
 - iat: issued at
 - exp: expiry
 - auth_time: time when the end user was authenticated

 An access token (when encoded as a JWT) may contain all these fields
 except the auth_time (since auth_time is not defined in the JWT spec).

 Given that your proposal actually does not define the authentication
 protocol to be used between the resource owner/end user and the
 authorisation server I am wondering whether it would be possible to
 just add the auth_time parameter (and maybe some of the optional
 parameters) to the access token. Then, you can skip the id token.

 How do I come up with that question? In Kerberos, for example, the
 above-listed information is carried within a single container (within
 the ticket) and so I am curious to hear why we have to send the
 information twice in OAuth (once in the access token, when the info is
 passed per value, and again via the id token).

 Maybe I missing something important here.

 Ciao
 Hannes



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


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

___
OAuth mailing list
OAuth@ietf.orgmailto: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 Milestone Update and Rechartering

[Anthony Nadalin]

Where is the confusion ?

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, May 14, 2014 10:59 AM
To: Brian Campbell
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

I know a number of people implementing


http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03

Having it on a RFC track may make sense.

I remain to be convinced that a4c ads anything other than confusion.

If the WG wants to take it up it should be aligned with Connect.  I think there 
are more important things to spend time on.


Sent from my iPhone

On May 14, 2014, at 2:24 PM, Brian Campbell 
bcampb...@pingidentity.commailto:bcampb...@pingidentity.com wrote:
I would object to 'OAuth Authentication' being picked up by the WG as a work 
item. The starting point draft has expired and it hasn't really been discusses 
since Berlin nearly a year ago.  As I recall, there was only very limited 
interest in it even then. I also don't believe it fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of Possession 
for Code Extension' for which there is an excellent starting point of 
http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativity 
simple security enhancement which addresses problems currently being 
encountered in deployments of native clients.


On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig 
hannes.tschofe...@gmx.netmailto:hannes.tschofe...@gmx.net wrote:
Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth
security mechanisms to use the proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-

Nov 2014 Submit 'Token introspection' to the IESG for consideration as a
Proposed Standard
Starting point: draft-richer-oauth-introspection-04

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as
a Proposed Standard
Starting point: draft-hunt-oauth-v2-user-a4c-01

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: draft-jones-oauth-token-exchange-00

-

We also updated the charter text to reflect the current situation. Here
is the proposed text:

-

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the
user share his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
  (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possession and token exchange.

The ongoing standardization effort within the OAuth working group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service and
standards for additional security of OAuth requests.

-

Feedback appreciated.

Ciao
Hannes  Derek



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



--
[Ping Identity logo]https://www.pingidentity.com/

Brian Campbell
Portfolio Architect
@

bcampb...@pingidentity.commailto:bcampb...@pingidentity.com

[phone]

+1 720.317.2061

Connect with us…

[twitter logo]https://twitter.com/pingidentity[youtube 
logo]https://www.youtube.com/user/PingIdentityTV[LinkedIn 
logo]https://www.linkedin.com/company/21870[Facebook 
logo]https://www.facebook.com/pingidentitypage[Google+ 
logo]https://plus.google.com/u/0/114266977739397708540[slideshare 
logo]http://www.slideshare.net/PingIdentity[flipboard 

Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

[Anthony Nadalin]

I agree with Phil on this one, there are implementations of this already and 
much interest

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, May 14, 2014 8:32 AM
To: Brian Campbell
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

On the contrary. I and others are interested.

We are waiting for the charter to pick up the work.

Regardless there will be a new draft shortly.

Phil

On May 14, 2014, at 5:24, Brian Campbell 
bcampb...@pingidentity.commailto:bcampb...@pingidentity.com wrote:
I would object to 'OAuth Authentication' being picked up by the WG as a work 
item. The starting point draft has expired and it hasn't really been discusses 
since Berlin nearly a year ago.  As I recall, there was only very limited 
interest in it even then. I also don't believe it fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of Possession 
for Code Extension' for which there is an excellent starting point of 
http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativity 
simple security enhancement which addresses problems currently being 
encountered in deployments of native clients.


On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig 
hannes.tschofe...@gmx.netmailto:hannes.tschofe...@gmx.net wrote:
Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth
security mechanisms to use the proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-

Nov 2014 Submit 'Token introspection' to the IESG for consideration as a
Proposed Standard
Starting point: draft-richer-oauth-introspection-04

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as
a Proposed Standard
Starting point: draft-hunt-oauth-v2-user-a4c-01

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: draft-jones-oauth-token-exchange-00

-

We also updated the charter text to reflect the current situation. Here
is the proposed text:

-

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the
user share his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
  (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possession and token exchange.

The ongoing standardization effort within the OAuth working group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service and
standards for additional security of OAuth requests.

-

Feedback appreciated.

Ciao
Hannes  Derek



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



--
[Ping Identity logo]https://www.pingidentity.com/

Brian Campbell
Portfolio Architect
@

bcampb...@pingidentity.commailto:bcampb...@pingidentity.com

[phone]

+1 720.317.2061

Connect with us…

[twitter logo]https://twitter.com/pingidentity[youtube 
logo]https://www.youtube.com/user/PingIdentityTV[LinkedIn 
logo]https://www.linkedin.com/company/21870[Facebook 
logo]https://www.facebook.com/pingidentitypage[Google+ 
logo]https://plus.google.com/u/0/114266977739397708540[slideshare 
logo]http://www.slideshare.net/PingIdentity[flipboard 
logo]http://flip.it/vjBF7[rss feed icon]https://www.pingidentity.com/blogs/


[Register for Cloud Identity Summit 2014 | Modern Identity 

Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

[Anthony Nadalin]

Please list the implementstions

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, May 14, 2014 10:59 AM
To: Brian Campbell
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

I know a number of people implementing


http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03

Having it on a RFC track may make sense.

I remain to be convinced that a4c ads anything other than confusion.

If the WG wants to take it up it should be aligned with Connect.  I think there 
are more important things to spend time on.


Sent from my iPhone

On May 14, 2014, at 2:24 PM, Brian Campbell 
bcampb...@pingidentity.commailto:bcampb...@pingidentity.com wrote:
I would object to 'OAuth Authentication' being picked up by the WG as a work 
item. The starting point draft has expired and it hasn't really been discusses 
since Berlin nearly a year ago.  As I recall, there was only very limited 
interest in it even then. I also don't believe it fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of Possession 
for Code Extension' for which there is an excellent starting point of 
http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativity 
simple security enhancement which addresses problems currently being 
encountered in deployments of native clients.


On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig 
hannes.tschofe...@gmx.netmailto:hannes.tschofe...@gmx.net wrote:
Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth
security mechanisms to use the proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-

Nov 2014 Submit 'Token introspection' to the IESG for consideration as a
Proposed Standard
Starting point: draft-richer-oauth-introspection-04

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as
a Proposed Standard
Starting point: draft-hunt-oauth-v2-user-a4c-01

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: draft-jones-oauth-token-exchange-00

-

We also updated the charter text to reflect the current situation. Here
is the proposed text:

-

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the
user share his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
  (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possession and token exchange.

The ongoing standardization effort within the OAuth working group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service and
standards for additional security of OAuth requests.

-

Feedback appreciated.

Ciao
Hannes  Derek



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



--
[Ping Identity logo]https://www.pingidentity.com/

Brian Campbell
Portfolio Architect
@

bcampb...@pingidentity.commailto:bcampb...@pingidentity.com

[phone]

+1 720.317.2061

Connect with us…

[twitter logo]https://twitter.com/pingidentity[youtube 
logo]https://www.youtube.com/user/PingIdentityTV[LinkedIn 
logo]https://www.linkedin.com/company/21870[Facebook 
logo]https://www.facebook.com/pingidentitypage[Google+ 
logo]https://plus.google.com/u/0/114266977739397708540[slideshare 

Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

[Anthony Nadalin]

There are folks that are not implementing connect for various reasons (i.e. 
security reasons, complexity reasons, etc.). thus this is compatible with 
connect if folks want to move on to connect,  we surely don’t use connect 
everwhere as it’s over kill where we only need a the functionality of a4c.

From: Chuck Mortimore [mailto:cmortim...@salesforce.com]
Sent: Wednesday, May 14, 2014 9:39 AM
To: Anthony Nadalin
Cc: Phil Hunt; Brian Campbell; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

Can you point to one publicly available or publicly documented implementation 
of a4c?I've never seen one.

I will say the a4c spec is almost 100% overlapped with OpenID Connect.   Some 
minor variations in claim names, but it adds 0 incremental value over what we 
have in Connect.

Connect is being successfully deployed at large scale.  It would be 
irresponsible for this working group to confuse developers and the industry 
with duplicate work, especially given this feels more like an argument over 
signing IPR agreements.

-cmort

On Wed, May 14, 2014 at 8:47 AM, Anthony Nadalin 
tony...@microsoft.commailto:tony...@microsoft.com wrote:
I agree with Phil on this one, there are implementations of this already and 
much interest

From: OAuth [mailto:oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org] On 
Behalf Of Phil Hunt
Sent: Wednesday, May 14, 2014 8:32 AM
To: Brian Campbell
Cc: oauth@ietf.orgmailto:oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

On the contrary. I and others are interested.

We are waiting for the charter to pick up the work.

Regardless there will be a new draft shortly.

Phil

On May 14, 2014, at 5:24, Brian Campbell 
bcampb...@pingidentity.commailto:bcampb...@pingidentity.com wrote:
I would object to 'OAuth Authentication' being picked up by the WG as a work 
item. The starting point draft has expired and it hasn't really been discusses 
since Berlin nearly a year ago.  As I recall, there was only very limited 
interest in it even then. I also don't believe it fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of Possession 
for Code Extension' for which there is an excellent starting point of 
http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativity 
simple security enhancement which addresses problems currently being 
encountered in deployments of native clients.

On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig 
hannes.tschofe...@gmx.netmailto:hannes.tschofe...@gmx.net wrote:
Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth
security mechanisms to use the proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-

Nov 2014 Submit 'Token introspection' to the IESG for consideration as a
Proposed Standard
Starting point: draft-richer-oauth-introspection-04

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as
a Proposed Standard
Starting point: draft-hunt-oauth-v2-user-a4c-01

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: draft-jones-oauth-token-exchange-00

-

We also updated the charter text to reflect the current situation. Here
is the proposed text:

-

Charter for Working Group


The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the
user share his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
  (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-pop-architecture-00.txt

[Anthony Nadalin]

I have to agree with Phil on this as there are already spec out there that use 
HoK and PoP , either of these work but prefer HoK as folks get confused with 
PoP as we have seen this within our company already

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
Sent: Thursday, April 3, 2014 11:32 AM
To: John Bradley; Phil Hunt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] New Version Notification for 
draft-hunt-oauth-pop-architecture-00.txt

I agree with what John wrote below.  Besides, PoP is more natural to say than 
HoK and certainly more natural to say than HOTK.  I'd like us to stay with the 
term Proof-of-Possession (PoP).

-- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Thursday, April 03, 2014 11:10 AM
To: Phil Hunt
Cc: oauth@ietf.orgmailto:oauth@ietf.org
Subject: Re: [OAUTH-WG] New Version Notification for 
draft-hunt-oauth-pop-architecture-00.txt

Some people and specs associate holder of key with asymmetric keys.  Proof of 
possession is thought to be a broader category including symmetric and key 
agreement eg http://tools.ietf.org/html/rfc2875.

NIST defines the term PoP Protocol 
http://fismapedia.org/index.php?title=Term:Proof_of_Possession_Protocol

In SAML the saml:SubjectConfirmation method  is called 
urn:oasis:names:tc:SAML:2.0:cm:holder-of-key

In WS* the term proof of possession is more common.

So I think for this document as an overview Proof of Possession (PoP) 
Architecture is fine.

John B.

On Apr 3, 2014, at 12:41 PM, Phil Hunt 
phil.h...@oracle.commailto:phil.h...@oracle.com wrote:

What was wrong with HOK?

Aside: Why was the so important in HOTK?

Phil

@independentid
www.independentid.comhttp://www.independentid.com/
phil.h...@oracle.commailto:phil.h...@oracle.com

On Apr 3, 2014, at 9:37 AM, Anil Saldhana 
anil.saldh...@redhat.commailto:anil.saldh...@redhat.com wrote:

Prateek,
  why not just use proof?

draft-hunt-oauth-proof-architecture-00.txt

Is that allowed by IETF?


Regards,
Anil

On 04/03/2014 11:30 AM, Prateek Mishra wrote:
key confirmed or key confirmation is another term that is widely used for 
these use-cases
I really *like* the name proof of possession, but I think the acronym PoP is 
going to be confused with POP.  HOTK has the advantage of not being a homonym 
for aything else.  What about Possession Proof?

-bill

William J. Mills
Paranoid MUX Yahoo!

On Thursday, April 3, 2014 1:38 AM, 
internet-dra...@ietf.orgmailto:internet-dra...@ietf.org 
internet-dra...@ietf.orgmailto:internet-dra...@ietf.org wrote:

A new version of I-D, draft-hunt-oauth-pop-architecture-00.txt
has been successfully submitted by Hannes Tschofenig and posted to the
IETF repository.

Name:draft-hunt-oauth-pop-architecture
Revision:00
Title:OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
Document date:2014-04-03
Group:Individual Submission
Pages:21
URL:
http://www.ietf.org/internet-drafts/draft-hunt-oauth-pop-architecture-00.txt
Status:
https://datatracker.ietf.org/doc/draft-hunt-oauth-pop-architecture/
Htmlized:  http://tools.ietf.org/html/draft-hunt-oauth-pop-architecture-00


Abstract:
  The OAuth 2.0 bearer token specification, as defined in RFC 6750,
  allows any party in possession of a bearer token (a bearer) to get
  access to the associated resources (without demonstrating possession
  of a cryptographic key).  To prevent misuse, bearer tokens must to be
  protected from disclosure in transit and at rest.

  Some scenarios demand additional security protection whereby a client
  needs to demonstrate possession of cryptographic keying material when
  accessing a protected resource.  This document motivates the
  development of the OAuth 2.0 proof-of-possession security mechanism.




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.orghttp://tools.ietf.org/.

The IETF Secretariat

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

___
OAuth mailing list
OAuth@ietf.orgmailto: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] IETF #89 OAuth Meeting Notes

[Anthony Nadalin]

I'm not convinced that scope should be in core

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of tors...@lodderstedt.net
Sent: Thursday, March 6, 2014 12:38 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] IETF #89 OAuth Meeting Notes

Hi,

regarding dynamic client registration: it has been suggested to merge core and 
meta data, or at least move some elements (such as scopes) to the core spec. 
Would you please add this?

regards,
Torsten.

Am 05.03.2014 13:43, schrieb Hannes Tschofenig:
 Hi al
 
 here are the notes from the OAuth f2f meeting this week:
 http://www.ietf.org/proceedings/89/minutes/minutes-89-oauth
 
 They are rather short! If someone took some more detailed notes please 
 send us a mail.
 
 Ciao
 Hannes  Derek
 
 
 ___
 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] IETF #89 OAuth Meeting Notes

[Anthony Nadalin]

+1  should not be merged

-Original Message-
From: Mike Jones 
Sent: Thursday, March 6, 2014 5:19 AM
To: Anthony Nadalin; tors...@lodderstedt.net; oauth@ietf.org
Subject: RE: [OAUTH-WG] IETF #89 OAuth Meeting Notes

I also disagree with moving scope into the core registration spec.  The 
metadata values in the core spec are those that are essential to use to achieve 
registration.  Those in the metadata spec are those that are useful in some 
applications but not needed by some others.  scope is of the second class.

-- Mike

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
Sent: Thursday, March 06, 2014 1:37 AM
To: tors...@lodderstedt.net; oauth@ietf.org
Subject: Re: [OAUTH-WG] IETF #89 OAuth Meeting Notes

I'm not convinced that scope should be in core

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of tors...@lodderstedt.net
Sent: Thursday, March 6, 2014 12:38 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] IETF #89 OAuth Meeting Notes

Hi,

regarding dynamic client registration: it has been suggested to merge core and 
meta data, or at least move some elements (such as scopes) to the core spec. 
Would you please add this?

regards,
Torsten.

Am 05.03.2014 13:43, schrieb Hannes Tschofenig:
 Hi al
 
 here are the notes from the OAuth f2f meeting this week:
 http://www.ietf.org/proceedings/89/minutes/minutes-89-oauth
 
 They are rather short! If someone took some more detailed notes please 
 send us a mail.
 
 Ciao
 Hannes  Derek
 
 
 ___
 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

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

Re: [OAUTH-WG] Working Group Versions of Refactored OAuth Dynamic Client Registration Specs

[Anthony Nadalin]

So the current core makes the registration_access_token  required and there are 
open registration endpoints, so this should be optional, there are also cases 
where the client_id is signed and that becomes the right to the registration 
endpoint

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
Sent: Friday, February 7, 2014 10:58 AM
To: oauth@ietf.org list
Subject: [OAUTH-WG] Working Group Versions of Refactored OAuth Dynamic Client 
Registration Specs

There are now OAuth working grouphttp://datatracker.ietf.org/wg/oauth/ 
versions of the refactored OAuth Dynamic Client Registration specifications:

* OAuth 2.0 Dynamic Client Registration Core Protocol

* OAuth 2.0 Dynamic Client Registration Metadata

* OAuth 2.0 Dynamic Client Registration Management Protocol

These versions address review comments by Phil Hunt and Tony Nadalin.  Phil is 
now also an author.  The data structures and messages used are the same as the 
previous versionshttp://self-issued.info/?p=1171.

The drafts are available at:

* http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-16

* http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-metadata-00

* http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-00

HTML formatted versions are also available at:

* https://self-issued.info/docs/draft-ietf-oauth-dyn-reg-16.html

* 
https://self-issued.info/docs/draft-ietf-oauth-dyn-reg-metadata-00.html

* 
https://self-issued.info/docs/draft-ietf-oauth-dyn-reg-management-00.html

-- Mike

P.S.  I also posted this notice at http://self-issued.info/?p=1180 and as 
@selfissued.

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

Re: [OAUTH-WG] Working Group Versions of Refactored OAuth Dynamic Client Registration Specs

[Anthony Nadalin]

Same is true for the registration_client_uri as I may not need/want this, 
should be optional

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
Sent: Thursday, March 6, 2014 7:02 AM
To: Mike Jones; oauth@ietf.org list
Subject: Re: [OAUTH-WG] Working Group Versions of Refactored OAuth Dynamic 
Client Registration Specs

So the current core makes the registration_access_token  required and there are 
open registration endpoints, so this should be optional, there are also cases 
where the client_id is signed and that becomes the right to the registration 
endpoint

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
Sent: Friday, February 7, 2014 10:58 AM
To: oauth@ietf.orgmailto:oauth@ietf.org list
Subject: [OAUTH-WG] Working Group Versions of Refactored OAuth Dynamic Client 
Registration Specs

There are now OAuth working grouphttp://datatracker.ietf.org/wg/oauth/ 
versions of the refactored OAuth Dynamic Client Registration specifications:

* OAuth 2.0 Dynamic Client Registration Core Protocol

* OAuth 2.0 Dynamic Client Registration Metadata

* OAuth 2.0 Dynamic Client Registration Management Protocol

These versions address review comments by Phil Hunt and Tony Nadalin.  Phil is 
now also an author.  The data structures and messages used are the same as the 
previous versionshttp://self-issued.info/?p=1171.

The drafts are available at:

* http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-16

* http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-metadata-00

* http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-00

HTML formatted versions are also available at:

* https://self-issued.info/docs/draft-ietf-oauth-dyn-reg-16.html

* 
https://self-issued.info/docs/draft-ietf-oauth-dyn-reg-metadata-00.html

* 
https://self-issued.info/docs/draft-ietf-oauth-dyn-reg-management-00.html

-- Mike

P.S.  I also posted this notice at http://self-issued.info/?p=1180 and as 
@selfissued.

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

Re: [OAUTH-WG] OAuth + Open ID Connect Meeting: Sunday, March 2

[Anthony Nadalin]

We agreed upon a time and then John decided to change it as some of the folks 
can't make it to the venue until after 1PM as they are flying in on Sunday

-Original Message-
From: Lucy Lynch [mailto:ly...@isoc.org] 
Sent: Wednesday, February 26, 2014 9:15 AM
To: John Bradley
Cc: Anthony Nadalin; Brian Campbell; oauth; Lucy Lynch
Subject: Re: [OAUTH-WG] OAuth + Open ID Connect Meeting: Sunday, March 2

On Wed, 26 Feb 2014, John Bradley wrote:

 I asked for the room from 12 to 5.  The chair had the time changed so 
 we reserved the room from 10 to 3pm.

 We would need to talk to Lucy to see if we could have the time 
 extended past 3 for additional OAuth related meetings.

 I don't know if the room is booked for something else after 3 but we 
 could likely find out.

I can check - it would help if everyone agreed on times and topics.

 John B.

 On Feb 26, 2014, at 1:57 AM, Anthony Nadalin tony...@microsoft.com wrote:

 Agree, the OAUTH meeting should change to afternoon

 -Original Message-
 From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian 
 Campbell
 Sent: Tuesday, February 25, 2014 2:56 PM
 To: John Bradley
 Cc: oauth
 Subject: Re: [OAUTH-WG] OAuth + Open ID Connect Meeting: Sunday, 
 March 2

 Yes, I'm familiar with life and I'm aware that things do change. And I have 
 no doubt that scheduling this stuff is more than a little difficult. But 
 with these Sunday meetings and the vast majority of us traveling 
 internationally, it'd be really helpful if the timing can be nailed down as 
 early as is reasonable and changes can be avoided.



 On Tue, Feb 25, 2014 at 12:58 PM, John Bradley ve7...@ve7jtb.com wrote:
 Yes.

 Things change that's life.



 Sent from my iPhone

 On Feb 25, 2014, at 8:16 PM, Brian Campbell 
 bcampb...@pingidentity.com
 wrote:

 Wasn't this originally announced with a different start time and 
 Connect and OAuth happening in the opposite order?


 On Tue, Feb 25, 2014 at 10:23 AM, Hannes Tschofenig 
 hannes.tschofe...@gmx.net wrote:

 Hi all,

 Lucy organized a room for our informal discussion about OAuth 
 (followed by the OpenID Connect meeting). We will start at 10am and 
 the room is reserved till 3pm. Palace C is the meeting room. At 
 some point in time the OAuth meeting will turn into the OpenID 
 Connect meeting. For those who are interested I will give a privacy 
 tutorial at 3pm in the Blenheim room.

 Mike, Nat, John, and others might have more information about the 
 agenda for the OpenID Connect meeting. For the OAuth meeting Derek 
 and I were planning to use the time to prepare the security 
 discussions for the official OAuth WG meeting. I am sure we will 
 arrange further meeting slots during the week to give enough room 
 for socializing and generating new ideas.

 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

 ___
 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 + Open ID Connect Meeting: Sunday, March 2

[Anthony Nadalin]

Agree, the OAUTH meeting should change to afternoon

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Tuesday, February 25, 2014 2:56 PM
To: John Bradley
Cc: oauth
Subject: Re: [OAUTH-WG] OAuth + Open ID Connect Meeting: Sunday, March 2

Yes, I'm familiar with life and I'm aware that things do change. And I have no 
doubt that scheduling this stuff is more than a little difficult. But with 
these Sunday meetings and the vast majority of us traveling internationally, 
it'd be really helpful if the timing can be nailed down as early as is 
reasonable and changes can be avoided.



On Tue, Feb 25, 2014 at 12:58 PM, John Bradley ve7...@ve7jtb.com wrote:
 Yes.

 Things change that's life.



 Sent from my iPhone

 On Feb 25, 2014, at 8:16 PM, Brian Campbell 
 bcampb...@pingidentity.com
 wrote:

 Wasn't this originally announced with a different start time and 
 Connect and OAuth happening in the opposite order?


 On Tue, Feb 25, 2014 at 10:23 AM, Hannes Tschofenig 
 hannes.tschofe...@gmx.net wrote:

 Hi all,

 Lucy organized a room for our informal discussion about OAuth 
 (followed by the OpenID Connect meeting). We will start at 10am and 
 the room is reserved till 3pm. Palace C is the meeting room. At some 
 point in time the OAuth meeting will turn into the OpenID Connect 
 meeting. For those who are interested I will give a privacy tutorial at 3pm 
 in the Blenheim room.

 Mike, Nat, John, and others might have more information about the 
 agenda for the OpenID Connect meeting. For the OAuth meeting Derek 
 and I were planning to use the time to prepare the security 
 discussions for the official OAuth WG meeting. I am sure we will 
 arrange further meeting slots during the week to give enough room for 
 socializing and generating new ideas.

 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

___
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] Draft Agenda

[Anthony Nadalin]

Could either Mike or I get 5 min for ActAS/OnBehalf of update?

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Monday, February 24, 2014 10:47 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Draft Agenda

Hi all,

we put a draft agenda online:
http://www.ietf.org/proceedings/89/agenda/agenda-89-oauth

Let us know whether this sounds reasonable for you.

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

Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!

[Anthony Nadalin]

So it's a tiny bit better but not sure it has captured all of what was being 
proposed to fix the original, still not there.

1. The signature on the software statement should be optional 
2. The software statement should be an assertion, the assertion can be whatever 
profiles exist, I understand the desire this to be a JWT but that is too 
limiting, for interop purposes this could be  as JWT assertion.
3. The idea was to be able to remove the client secrets to reduce required 
management for secrets, we need to get away from this



-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Tuesday, January 28, 2014 8:05 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!

Hi all,

as you have seen from the meeting minutes of our recent status chat it is time 
to proceed with the dynamic client registration work.

The earlier version of the dynamic client registration document was split into 
three parts, namely
  (1) the current working group draft containing only minimal functionality,
  (2) a document describing meta-data, and
  (3) a document containing management functionality.

This change was made as outcome of the discussions we had more or less over the 
last 9 months.

The latter two documents are individual submissions at this point. New content 
is not available with the recent changes. So, it is one of those document 
management issues.

I had a chat with Stephen about WG adoption of the two individual submissions 
as WG items. It was OK for him given that it is a purely document management 
action. However, before we turn the documents into WG items we need your 
feedback on a number of issues:

1) Do you have concerns with the document split? Do you object or approve it?
2) Is the separation of the functionality into these three documents correct? 
Should the line be drawn differently?
3) Do you have comments on the documents overall?

We would like to receive high-level feedback within a week. We are also eager 
to hear from implementers and other projects using the dynamic client 
registration work (such as OpenID Connect, UMA, the BlueButton/GreenButton 
Initiative, etc.)

For more detailed reviews please wait till we re-do the WGLC (which we plan to 
do soon). We have to restart the WGLC due to discussions last years and the 
resulting changes to these documents.

Ciao
Hannes  Derek

PS: Derek and I also think that Phil should become co-auhor of these documents 
for his contributions.

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

Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00

[Anthony Nadalin]

We need to avoid encoding secrets and authentication with client_id as 
authentication is not part of our mission

From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Nat 
Sakimura
Sent: Monday, November 4, 2013 1:38 PM
To: Hannes Tschofenig
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00

Since the client_id is supposed to be opaque, it would probably be better to 
JWE encrypt (note: all JWE encryption are integrity protected as well) by the 
authorization server upon issuing it to the client. This way, we have exactly 
one way of doing the things, and it works for both symmetric and asymmetric 
case.

I see this more useful in the case of symmetric client secret.

If the client were just using public key crypto to authenticate itself to the 
server, using the URI of the location of the client metadata as the client_id 
would suffice.

This has an advantage of smaller client_id.

2013/11/2 Hannes Tschofenig 
hannes.tschofe...@gmx.netmailto:hannes.tschofe...@gmx.net
Hi John,

thanks for the super-quick response.


Am 01.11.13 19:18, schrieb John Bradley:

The client_id would continue to be opaque to the client as it is now.
The AS can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and
provide integrity if it is using a symmetric key (probably the
simplest thing if we are talking about a single registration endpoint
paired with a single AS)  In more complicated scenarios where perhaps
a group of AS share a single registration endpoint you probably want
to use asymmetric signature  then asymmetric encryption + integrity.
Those are deployment decisions that need to be documented but can be
transparent to teh client.

Maybe it would be good to state that in the document that this is a possible 
option without introducing further complications (other than the verification 
procedure is different). If the AS signs the JWT then it just needs to compare 
whether the issuer field matches what it had previously put in there. If 
someone else signs the JWT then it needs to check with some trust anchor store 
or something similar whether it trusts that specific issuer.



Sorry to my mind it is obvious that the JWT would be integrity
protected/signed for all clients including clients using asymmetric
authentication to the token endpoint, and and
signed+encrypted+integrity for clients using symmetric
authentication.   That can be made clearer.

It would be good to say that because the effort is rather low and there are 
benefits in doing so.


It might make sense to assume the issuer is just the AS but the AS
can do that without the benefit of a spec now, as there is no
interoperability issue.

The spec defining the JWT structure and signing and encryption
methods has the most benefit when you don't have such a tight
coupling between registration and AS.

That is likely why Justin and I didn't think a spec was necessary for
the simple case other than to show people this is possible with the
existing registration spec.

I think there is value in providing that information for implementers even 
though it does not require new extensions or so.


I am OK with strengthening the wording on signing/integrity
protecting and encryption.  eg if a symmetric key is included the JWT
MUST be encrypted.

Cool.


I don't necessarily want to make any algorithm a must as that limits
algorithm agility in the future.
OK.


Thanks for giving it a read, see you Sunday I expect.
Unfortunately not since I am unable to attend the upcoming IETF meeting. Derek 
will run the show.

Ciao
Hannes


John B.


On Nov 1, 2013, at 2:32 PM, Hannes Tschofenig
hannes.tschofe...@gmx.netmailto:hannes.tschofe...@gmx.net wrote:
Hi John, Hi all,

I read your document and here a few remarks.

In the dynamic client registration conference calls the topic of
the stateless client was raised since there was the argument in the
air that the current OAuth 2.0 RFC requires clients to be stateless
due to the nature of the client identifier.

It seems that you have found a way to make the client stateless
with regard to the client identifier (i.e., that the authorization
server does not need to store information about the client) by
dumping state information in the client identifier itself. In your
case you use a JWT, which is clever.

Since RFC 6749 explicitly says that the client identifier string
size is left undefined  and that the client should avoid making
assumptions about the identifier size I don't see a problem with
the proposed approach.

Now, there is one issue that I am wondering about. The client
identifier itself is not sufficient for authorizing the client (for
confidential clients). Instead, there is typically the need to have
a secret. Now, the secret is not conveyed in the JWT, at least not
in the way you have define it. You could of course do that and
there is a document that provides prior art, see
http://www.ietf.org/rfc/rfc5077 The story essentially is that the
structure (JWT in