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] 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 wal

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

[nadalin]

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

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

[nadalin]

ms that are in the 
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

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-00&data=02%7C01%7Ctonynad%40microsoft.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636903400616347061&sdata=ePmwaD%2FHCRZhRx%2FwZbb3U72%2FhBalPoFPKtQ67QTxIRw%3D&reserved=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%2Foauth&data=02%7C01%7Ctonynad%40microsoft.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636903400616357060&sdata=zcxw1IR3kNbuZ9u58OOJDv9pLb7cUCooDtlIUH7tS%2Fw%3D&reserved=0

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

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%2Foauth&data=02%7C01%7CMichael.Jon
>> es%40microsoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f14
>> 1af91ab2d7cd011db47%7C1%7C0%7C636996821305207975&sdata=dAokWYxwGW
>> SRXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3D&reserved=0
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones
> %40microsoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af
> 91ab2d7cd011db47%7C1%7C0%7C636996821305207975&sdata=dAokWYxwGWSRXy
> rzs4V%2BWMXcMD482nhyARt28me4xbE%3D&reserved=0

___
OAuth mailing list
OAuth@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636996821305207975&sdata=dAokWYxwGWSRXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3D&reserved=0

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&data=02%7C01%7Ctonynad%40microsoft.com%7C24500550fdb347a700f808d71dbd3661%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637010570831332090&sdata=DdWZCoppTjVZTdtgt%2FER7N59HHmcKEslU8zJYwCBz0Q%3D&reserved=0>%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jon
>> es%40microsoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7Ctonynad%40microsoft.com%7C24500550fdb347a700f808d71dbd3661%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637010570831342083&sdata=QwDmcdAgVzCSD2jWgLgbc%2BpPMld3dVwoGUyuk5HlfT4%3D&reserved=0>%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f14
>> 1af91ab2d7cd011db47%7C1%7C0%7C636996821305207975&sdata=dAokWYxwGW
>> SRXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3D&reserved=0
>
> ___
> OAuth mailing list
> OAuth@ietf.org<mailto:OAuth@ietf.org>

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] 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] draft-ietf-oauth-revocation

[Anthony Nadalin]

Yes on token_type

Sent from my Windows Phone

From: Torsten Lodderstedt
Sent: ‎2/‎3/‎2013 6:02 AM
To: OAuth WG
Subject: [OAUTH-WG] draft-ietf-oauth-revocation

Hi all,

before I publish a new revision of the draft, I would like to sort out
the following issues and would like to ask you for your feedback.

- Authorization vs. access grant vs. authorization grant: I propose to
use "authorization grant".
- invalid_token error code: I propose to use the new error code
"invalid_parameter" (as suggested by Peter and George). I don't see the
need to register it (see
http://www.ietf.org/mail-archive/web/oauth/current/msg10604.html) but
would like to get your advice.
- Donald F. Coffin raised the need for a token_type parameter to the
revocation request. Shall we re-consider this topic?

best regards,
Torsten.
___
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] How soon until last call on introspection and revocation

[Anthony Nadalin]

I think that there are still fundamental design disagreements that would need 
to be resolved.

Sent from Windows Mail

From: Justin Richer
Sent: ‎February‎ ‎6‎, ‎2013 ‎6‎:‎57‎ ‎AM
To: Hannes Tschofenig
CC: IETF oauth WG
Subject: Re: [OAUTH-WG] How soon until last call on introspection and revocation

As editor of introspection draft, I would like to see it become a
working group item. After talking with the chairs, there appears to be
some friction with the amount of open working items that the working
group has right now, though, leading to hesitation to add more to our
official plate.

That said, it doesn't mean we can't all just *work* on it, and I'm
actively editing it based on feedback. We're implementing and deploying
it in our own systems right now, too. I'm tracking issues to the draft
here if you have any direct changes (or pull requests!):

   https://github.com/jricher/oauth-spec/issues

So I hope that we can at least stabilize the functionality of the spec
so that by the time the IETF process can start to chew on it in an
official fashion, it will be mostly baked and we can run it through
relatively quickly.

  -- Justin

On 02/06/2013 09:45 AM, Hannes Tschofenig wrote:
> Hi Todd,
>
> two answers:
>
> 1) Token Revocation:
>
> I had initiated a Working Group Last Call for the token revocation document 
> end of November:
> http://www.ietf.org/mail-archive/web/oauth/current/msg10102.html
>
> As you have seen on the list, this has generated a fair amount of discussion.
>
> I hope that Torsten, the draft editor, is able to produce a new draft version 
> quickly with a resolution of the open issues that is acceptable to the rest 
> of the group.
>
> Then, we will have to judge whether the document can move forward to the IESG.
>
> 2) Introspection
>
> That document is not even a working group item.
>
> Ciao
> Hannes
>
> On Feb 6, 2013, at 4:26 PM, Todd W Lainhart wrote:
>
>> Does anyone have any intuition as to how far away we are on last call for 
>> introspection and revocation?
> ___
> 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] Registration: HAL _links structure and client self-URL

[Anthony Nadalin]

I doubt that the ToS and Privacy Policy will be different for a given Trust 
Framework provider, as these are all bilateral agreements, I do expect these to 
be different between trust framework providers though

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Nat 
Sakimura
Sent: Tuesday, February 12, 2013 12:27 PM
To: Justin Richer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: HAL _links structure and client self-URL

Let me explain a bit more.

A trust framework may supply several ToS and Privacy Policy options much like 
CC licenses.
If we want to really automate the things, you really need it.
Otherwise, the service's owner need to go read the ToS and Privacy Policy in 
person and makes the dynamic registration not so dynamic.
Those option should be available through Discovery.

In Discovery, the server may provide multiple options, out of which the client 
picks one. Think of something like Basic and Premium service. In the 
Registration response, then, should be the one that was picked by the client / 
assigned by the server.

(The notion is closely related to the implicit consent model for the end users, 
which is in active discussion in bunch of places, by the way.)

Nat

2013/2/13 Justin Richer :
> I agree with the previous statement that the AS's privacy/TOS would be 
> better handled through discovery, since it's not likely to change per 
> client instance.
>
>  -- Justin
>
>
> On 02/12/2013 03:04 PM, John Bradley wrote:
>>
>> There are two TOS and privacy policies.
>>
>> One for the AS that the client is agreeing to by registering.  Will 
>> it hold up in court?  don't know Facebook is doing this.
>> The link would be a reference to a human readable file that the 
>> client
>> (RP) can have someone look over before using the connection.
>> This policy may relate to how long the client can cache info etc.
>>
>> The other is the privacy policy of the client that may be presented 
>> as a click through from the Authorization server.  In general the 
>> user is not explicitly accepting this, only implicitly accepting it 
>> by continuing to the RP after having been given a chance to look at it if 
>> they want.
>>
>> These are very US fuse on privacy but ignoring them is probably a mistake.
>>
>> John B.
>> On 2013-02-12, at 4:56 PM, Justin Richer  wrote:
>>
>>> One question though: How exactly would the client, a software 
>>> application, agree to the TOS? Is it supposed to fetch the content 
>>> of the tos_url and do some processing on it? I wasn't under the 
>>> impression that the tos_url contents were machine readable. Is it 
>>> supposed to present that to the user somehow? It seems that's a 
>>> better thing for the server to do at Authorization time, since it's got the 
>>> user's attention.
>>>
>>> Remember, this is meant to be for *automated* registration. The 
>>> developer of the Client has no say at this stage of the game.
>>>
>>> So, I think this is a bit of a red herring, to be honest.
>>>
>>> -- Justin
>>>
>>> On 02/12/2013 02:52 PM, John Bradley wrote:

 The current privacy policy and TOS URL in registration are the ones 
 for the Client.

 Nat and I discussed adding ones for the Authorization server that 
 the client agrees to as separate from ones that the user is agreeing to.

 The Authorization servers TOS would be in discovery and perhaps in 
 the registration response to indicate what the client is agreeing to.

 As there rare standard relationships that cover this links Nat was 
 speculating that they could be part of the _links object.

 That aside confirming the terms of service that the client has 
 agreed to in some way is probably a good thing in the registration 
 response.

 John B.

 On 2013-02-12, at 4:25 PM, Mike Jones 
 wrote:

> Part of the REST/JSON philosophy is that interfaces should be as 
> simple and developer-friendly as possible.  XML was rejected by 
> developers, in part, because of the self-describing nature of the 
> structure, which required extra syntax that was often not useful 
> in practice.  Trying to re-impose that structure using extra JSON 
> syntax conventions is just asking developers to have an allergic 
> reaction to our specs upon encountering them.  The syntactic 
> complexity and *surprise factor* isn't worth the limited semantic 
> benefits of using "_links".
>
> Since you bring up privacy policy and terms of service, I'll note 
> that the OAuth Dynamic Registration spec already has these fields 
> to address
> those:
> policy_url
> tos_url
>
> Those have been working fine for OpenID Connect too.  There's no 
> need to likewise convolve them to add the extra syntax that you describe 
> below.
>
> (BTW, in a private thread, John Bradley pointed out that what the 
> two of you tal

Re: [OAUTH-WG] [jose] Meeting for people interested in OpenID Connect at IETF#86 in Sun Mar 10

[Anthony Nadalin]

I thought it was Sunday

-Original Message-
From: jose-boun...@ietf.org [mailto:jose-boun...@ietf.org] On Behalf Of Barry 
Leiba
Sent: Saturday, March 2, 2013 11:58 AM
To: John Bradley
Cc: openid-connect-inte...@googlegroups.com; Group Group; oauth@ietf.org WG; 
; webfin...@ietf.org
Subject: Re: [jose] [OAUTH-WG] Meeting for people interested in OpenID Connect 
at IETF#86 in Sun Mar 10

> The eventbrite page for people wanting to attend the openID Connect 
> session prior to IETF86 is now available at:
> http://openid-ietf-86.eventbrite.com/

That page says this:
   OpenID Meeting at IETF 86
   The OpenID Foundation
   Thursday, April 11, 2013 from 1:00 PM to 4:00 PM (EDT)
   Orlando, FL

I do hope it means Thursday, 7 March.  11 April is about a month
*after* the IETF meeting.

Barry
___
jose mailing list
j...@ietf.org
https://www.ietf.org/mailman/listinfo/jose



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

Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

[Anthony Nadalin]

Agree

From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Phil 
Hunt
Sent: Monday, May 20, 2013 9:42 AM
To: Justin Richer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

This draft isn't ready for LC.

Phil

On 2013-05-20, at 8:49, Justin Richer 
mailto:jric...@mitre.org>> wrote:
But also keep in mind that this is last-call, and that we don't really want to 
encourage avoidable drastic changes at this stage.

 -- Justin

On 05/20/2013 11:21 AM, Phil Hunt wrote:
Keep in mind there may be other changes coming.

The issue is that new developers can't figure out what token is being referred 
to.

Phil

On 2013-05-20, at 8:09, Justin Richer 
mailto:jric...@mitre.org>> wrote:
Phil Hunt's review of the Dynamic Registration specification has raised a 
couple of issues that I felt were getting buried by the larger discussion 
(which I still strongly encourage others to jump in to). Namely, Phil has 
suggested a couple of syntax changes to the names of several parameters.


1) expires_at -> client_secret_expires_at
2) issued_at -> client_id_issued_at
3) token_endpoint_auth_method -> token_endpoint_client_auth_method


I'd like to get a feeling, especially from developers who have deployed this 
draft spec, what we ought to do for each of these:

 A) Keep the parameter names as-is
 B) Adopt the new names as above
 C) Adopt a new name that I will specify

In all cases, clarifying text will be added to the parameter *definitions* so 
that it's more clear to people reading the spec what each piece does. Speaking 
as the editor: "A" is the default as far as I'm concerned, since we shouldn't 
change syntax without very good reason to do so. That said, if it's going to be 
better for developers with the new parameter names, I am open to fixing them 
now.

Naming things is hard.

 -- Justin
___
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] Proposed Syntax Changes in Dynamic Registration

[Anthony Nadalin]

So, I really don’t understand why dynamic registration is in scope, I 
understand this relative to OpenID Connect but not OAuth, if this is indeed in 
scope then I would have expected that the endpoint be based upon SCIM and not 
something else like what has been done here.

From: Justin Richer [mailto:jric...@mitre.org]
Sent: Monday, May 20, 2013 11:10 AM
To: Anthony Nadalin
Cc: Phil Hunt; oauth@ietf.org
Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

Tony, can you be more specific? What needs to be changed in your opinion? What 
text changes would you suggest?

 -- Justin
On 05/20/2013 02:09 PM, Anthony Nadalin wrote:
Agree

From: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org> 
[mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt
Sent: Monday, May 20, 2013 9:42 AM
To: Justin Richer
Cc: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

This draft isn't ready for LC.

Phil

On 2013-05-20, at 8:49, Justin Richer 
mailto:jric...@mitre.org>> wrote:
But also keep in mind that this is last-call, and that we don't really want to 
encourage avoidable drastic changes at this stage.

 -- Justin


On 05/20/2013 11:21 AM, Phil Hunt wrote:
Keep in mind there may be other changes coming.

The issue is that new developers can't figure out what token is being referred 
to.

Phil

On 2013-05-20, at 8:09, Justin Richer 
mailto:jric...@mitre.org>> wrote:
Phil Hunt's review of the Dynamic Registration specification has raised a 
couple of issues that I felt were getting buried by the larger discussion 
(which I still strongly encourage others to jump in to). Namely, Phil has 
suggested a couple of syntax changes to the names of several parameters.


1) expires_at -> client_secret_expires_at
2) issued_at -> client_id_issued_at
3) token_endpoint_auth_method -> token_endpoint_client_auth_method


I'd like to get a feeling, especially from developers who have deployed this 
draft spec, what we ought to do for each of these:

 A) Keep the parameter names as-is
 B) Adopt the new names as above
 C) Adopt a new name that I will specify

In all cases, clarifying text will be added to the parameter *definitions* so 
that it's more clear to people reading the spec what each piece does. Speaking 
as the editor: "A" is the default as far as I'm concerned, since we shouldn't 
change syntax without very good reason to do so. That said, if it's going to be 
better for developers with the new parameter names, I am open to fixing them 
now.

Naming things is hard.

 -- Justin
___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth


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

Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

[Anthony Nadalin]

I totally disagree with your characterization of SCIM, while it can be used 
from server to server (provision one system to another) it can also be client 
to endpoint (initial provisioning and JIT provisioning). SCIM is fairly simple 
(but can be complex), I also have concerns about SCIM not being 100% restful 
but that does not stop us from using it. I also agree that we should let OAuth 
do what it’s good at and don’t try to force it into something that it’s not. We 
already have OAuth doing dynamic registration, I don’t think there is a need to 
force it into OAuth.


From: Justin Richer [mailto:jric...@mitre.org]
Sent: Wednesday, May 22, 2013 1:35 PM
To: Anthony Nadalin
Cc: Phil Hunt; oauth@ietf.org
Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

I'm not sure why you don't think it's in scope, it's in the working group's 
charter:

  http://www.ietf.org/dyn/wg/charter/oauth-charter.html

So ... it's definitely in scope, and has been for over a year and a half. This 
is the tenth version of this document-- an IETF Working Group document at 
that-- that's been posted to the group with every revision and there has been 
significant conversation around it, especially over the last six months since I 
took over the editor role. There are also a handful of implementations of this, 
and while most of them are built to do OpenID Connect or UMA (which are 
directly built on OAuth), I know there are some that also do plain OAuth. (Not 
the least of which is one that I have personally implemented and deployed.)

SCIM doesn't solve client management particularly well, since it's made for 
users more than anything. The usage model of SCIM is also quite different -- 
it's really intended to be used between two servers to transfer information, as 
opposed to handling self-asserted claims. I understand that some 
implementations like UAA have done their static registration using a SCIM 
profile, but it's not dynamic registration, really. I think it's too much of a 
square-peg-round-hole problem, at least with SCIM as it is today; so let SCIM 
do what it's good at, and don't try to force it into something it's not.

Furthermore, be careful not to conflate SCIM with REST. Ultimately, Dynamic 
Registration was meant to be a fairly simple REST/JSON API that would be easy 
to implement, especially for clients. Just because SCIM is RESTful doesn't mean 
it's a good structure for other RESTful APIs. Namely, I don't think the extra 
structure and hooks with SCIM really buy you anything here, especially with the 
additions and changes you'd have to make to SCIM.

And finally, nobody to date has actually written a proposal that is even 
remotely SCIM based.

 -- Justin
On 05/22/2013 02:39 PM, Anthony Nadalin wrote:
So, I really don’t understand why dynamic registration is in scope, I 
understand this relative to OpenID Connect but not OAuth, if this is indeed in 
scope then I would have expected that the endpoint be based upon SCIM and not 
something else like what has been done here.

From: Justin Richer [mailto:jric...@mitre.org]
Sent: Monday, May 20, 2013 11:10 AM
To: Anthony Nadalin
Cc: Phil Hunt; oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

Tony, can you be more specific? What needs to be changed in your opinion? What 
text changes would you suggest?

 -- Justin
On 05/20/2013 02:09 PM, Anthony Nadalin wrote:
Agree

From: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org> 
[mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt
Sent: Monday, May 20, 2013 9:42 AM
To: Justin Richer
Cc: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

This draft isn't ready for LC.

Phil

On 2013-05-20, at 8:49, Justin Richer 
mailto:jric...@mitre.org>> wrote:
But also keep in mind that this is last-call, and that we don't really want to 
encourage avoidable drastic changes at this stage.

 -- Justin



On 05/20/2013 11:21 AM, Phil Hunt wrote:
Keep in mind there may be other changes coming.

The issue is that new developers can't figure out what token is being referred 
to.

Phil

On 2013-05-20, at 8:09, Justin Richer 
mailto:jric...@mitre.org>> wrote:
Phil Hunt's review of the Dynamic Registration specification has raised a 
couple of issues that I felt were getting buried by the larger discussion 
(which I still strongly encourage others to jump in to). Namely, Phil has 
suggested a couple of syntax changes to the names of several parameters.


1) expires_at -> client_secret_expires_at
2) issued_at -> client_id_issued_at
3) token_endpoint_auth_method -> token_endpoint_client_auth_method


I'd like to get a feeling, especially from developers who have deployed this 
draft spec, what we ought to do for each of these:

 A) Keep th

Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

[Anthony Nadalin]

My mistake, was to say, We already have OpenID Connect doing dynamic 
registration, I don’t think there is a need to force it into OAuth.

From: Phil Hunt [mailto:phil.h...@oracle.com]
Sent: Wednesday, May 22, 2013 3:16 PM
To: Anthony Nadalin
Cc: Justin Richer; oauth@ietf.org
Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

I'm having trouble understanding
We already have OAuth doing dynamic registration, I don’t think there is a need 
to force it into OAuth.


I would be open to a scim dyn reg version. Particularly to discuss instance 
metadata mgt which scim is good at and the credential managemenr/bootstrap 
process as it pertains to oauth.  Never-the-less the overwhelming priority has 
been apparently to simply standardize oidc and uma implementations as is. This 
I am not comfortable with but i can live with if there is give and take.

I feel the subject is well in charter and is an important issue due to the 
life-cycle management issues behind clients and the need to make public clients 
the security equiv. of confidential clients.

Phil

On 2013-05-22, at 14:22, Anthony Nadalin 
mailto:tony...@microsoft.com>> wrote:
I totally disagree with your characterization of SCIM, while it can be used 
from server to server (provision one system to another) it can also be client 
to endpoint (initial provisioning and JIT provisioning). SCIM is fairly simple 
(but can be complex), I also have concerns about SCIM not being 100% restful 
but that does not stop us from using it. I also agree that we should let OAuth 
do what it’s good at and don’t try to force it into something that it’s not. We 
already have OAuth doing dynamic registration, I don’t think there is a need to 
force it into OAuth.


From: Justin Richer [mailto:jric...@mitre.org]
Sent: Wednesday, May 22, 2013 1:35 PM
To: Anthony Nadalin
Cc: Phil Hunt; oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

I'm not sure why you don't think it's in scope, it's in the working group's 
charter:

  http://www.ietf.org/dyn/wg/charter/oauth-charter.html

So ... it's definitely in scope, and has been for over a year and a half. This 
is the tenth version of this document-- an IETF Working Group document at 
that-- that's been posted to the group with every revision and there has been 
significant conversation around it, especially over the last six months since I 
took over the editor role. There are also a handful of implementations of this, 
and while most of them are built to do OpenID Connect or UMA (which are 
directly built on OAuth), I know there are some that also do plain OAuth. (Not 
the least of which is one that I have personally implemented and deployed.)

SCIM doesn't solve client management particularly well, since it's made for 
users more than anything. The usage model of SCIM is also quite different -- 
it's really intended to be used between two servers to transfer information, as 
opposed to handling self-asserted claims. I understand that some 
implementations like UAA have done their static registration using a SCIM 
profile, but it's not dynamic registration, really. I think it's too much of a 
square-peg-round-hole problem, at least with SCIM as it is today; so let SCIM 
do what it's good at, and don't try to force it into something it's not.

Furthermore, be careful not to conflate SCIM with REST. Ultimately, Dynamic 
Registration was meant to be a fairly simple REST/JSON API that would be easy 
to implement, especially for clients. Just because SCIM is RESTful doesn't mean 
it's a good structure for other RESTful APIs. Namely, I don't think the extra 
structure and hooks with SCIM really buy you anything here, especially with the 
additions and changes you'd have to make to SCIM.

And finally, nobody to date has actually written a proposal that is even 
remotely SCIM based.

 -- Justin
On 05/22/2013 02:39 PM, Anthony Nadalin wrote:
So, I really don’t understand why dynamic registration is in scope, I 
understand this relative to OpenID Connect but not OAuth, if this is indeed in 
scope then I would have expected that the endpoint be based upon SCIM and not 
something else like what has been done here.

From: Justin Richer [mailto:jric...@mitre.org]
Sent: Monday, May 20, 2013 11:10 AM
To: Anthony Nadalin
Cc: Phil Hunt; oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

Tony, can you be more specific? What needs to be changed in your opinion? What 
text changes would you suggest?

 -- Justin
On 05/20/2013 02:09 PM, Anthony Nadalin wrote:
Agree

From: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org> 
[mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt
Sent: Monday, May 20, 2013 9:42 AM
To: Justin Richer
Cc: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re

Re: [OAUTH-WG] JWT: add "iss" and "aud" to Reserved Header Parameter Names in JWE

[Anthony Nadalin]

So there could be privacy issues on why I would not want the ISS or AUD outside 
the encrypted payload

From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Dick 
Hardt
Sent: Tuesday, May 28, 2013 9:34 AM
To: O Auth WG
Subject: Re: [OAUTH-WG] JWT: add "iss" and "aud" to Reserved Header Parameter 
Names in JWE

Following up on this topic ...

On Wed, May 1, 2013 at 2:12 PM, Dick Hardt 
mailto:dick.ha...@gmail.com>> wrote:
"iss" and "aud" would be optional parameters in a JWE. These parameters are in 
the payload, but since it is encrypted, the payload must be decrypted before 
they can be read. Some times knowing these parameters is required to be able to 
decrypt the payload ...

These would be additions to 9.3.1 in the JWT specification.

Why "iss" is needed:

Bob and Charlie each gave Alice a KID and a symmetric key to use to verify and 
decrypt tokens from them.

The App and Alice share keys so Alice knows it is the App.

The User authorizes Bob to give the App a token (which authorizes the App to do 
something)

The App gives the token to Alice.

Since Alice indirectly received the token,  the only way for Alice to know who 
sent the token, is to look at the KID as the "iss" claim is encrypted. If the 
"kid" values are GUIDs, then Alice can just look up the "kid" and retrieve the 
associated symmetric key, and then decrypt and verify the token and THEN see 
who sent it. If there is a collision in KID values (Bon and Charlie gave the 
same KID for different keys), then Alice will not know which symmetric key to 
use.

Why "aud" is needed:

Dave gives a KID and symmetric key to Ellen, and Frank gives a KID and 
symmetric key to Gwen.

Ellen and Gwen trust each other and know how to talk to each other. Gwen does 
not know Dave. Ellen does not know Frank

The App and Gwen share keys so Gwen knows it is the App.

The User authorizes Dave to give the App a token

Dave gives the token to Gwen (Dave does not have a relationship with Ellen)

Gwen now has a token that Ellen can decrypt and verify, but has no method for 
knowing that Ellen can do that. The "aud" property would allow Gwen to give the 
token to Ellen to decrypt and verify.



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

Re: [OAUTH-WG] SAML-like ActAs

[Anthony Nadalin]

You can accomplish the ActAs semantics with Assertions profile, while a bit 
clumsy the basics are in place, the only issue is that you don't have any way 
to indicate the formal semantics

From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Prateek Mishra
Sent: Friday, July 19, 2013 9:03 AM
To: Manfred Steyer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] SAML-like ActAs

Hi Manfred,

This is an area of interest to us and we have done some profiling in our 
implementation.

Generally speaking, we work with the assertion profiles as a starting point. 
They allow for WS-Trust
like token exchanges and (implicitly) support ActAs or OnBehalfOf.  But they do 
need additional profiling
to offer genuine interoperability in this area.



https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/

https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/

https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/

What use-cases do you have in mind? I am not sure I follow what you mean by "a 
resource server could delegate a subset of the delegated rights to another 
resource server".

- prateek


Hi,

are there plans for supporting delegation-styles like ActAs or OnBehalfOf in 
SAML?

If this was possible, a resource server could delegate a subset of the 
delegated rights to another resource server. This could be a very important 
thing, when one wants to use OAuth 2 within an enterprise-environment.

I know, that OAuth 2 has been created for web-scenarios, but it's a fact that 
OAuth 2 is used as a "REST-friedly" alternative to WS-* in the area of 
service-security.

Would it be the right way, to define an Extension Grants for such a scenario?

Wishes,
Manfred




___

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] Fwd: New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt

[Anthony Nadalin]

So is the intent to provide an enterprise authentication claim? I would think 
that the proposal would use JWT as the token and then define the appropriate 
claim in the JWT

From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Phil 
Hunt
Sent: Monday, July 29, 2013 1:14 AM
To: oauth@ietf.org WG
Subject: [OAUTH-WG] Fwd: New Version Notification for 
draft-hunt-oauth-v2-user-a4c-00.txt

FYI.  I have been noticing a substantial number of sites acting as OAuth 
Clients using OAuth to authenticate users.

I know several of us have blogged on the issue over the past year so I won't 
re-hash it here.  In short, many of us recommended OIDC as the correct 
methodology.

Never-the-less, I've spoken with a number of service providers who indicate 
they are not ready to make the jump to OIDC, yet they agree there is a desire 
to support authentication only (where as OIDC does IDP-like services).

This draft is intended as a minimum authentication only specification.  I've 
tried to make it as compatible as possible with OIDC.

For now, I've just posted to keep track of the issue so we can address at the 
next re-chartering.

Happy to answer questions and discuss.

Phil

@independentid
www.independentid.com
phil.h...@oracle.com




Begin forwarded message:


From: internet-dra...@ietf.org
Subject: New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt
Date: 29 July, 2013 9:49:41 AM GMT+02:00
To: Phil Hunt mailto:phil.h...@yahoo.com>>, Phil Hunt 
mailto:n...@ietfa.amsl.com>>, Phil Hunt <>


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

Filename: draft-hunt-oauth-v2-user-a4c
Revision: 00
Title:OAuth 2.0 User Authentication For Client
Creation date: 2013-07-29
Group: Individual Submission
Number of pages: 9
URL: 
http://www.ietf.org/internet-drafts/draft-hunt-oauth-v2-user-a4c-00.txt
Status:  http://datatracker.ietf.org/doc/draft-hunt-oauth-v2-user-a4c
Htmlized:http://tools.ietf.org/html/draft-hunt-oauth-v2-user-a4c-00


Abstract:
  This specification defines a new OAuth2 endpoint that enables user
  authentication session information to be shared with client
  applications.




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] Informal Dinner Discussion; Thursday @ 19:00

[Anthony Nadalin]

It's called exercise or take the S7, this also give you a culture experience of 
getting away from the hotel and IETF crowd.

From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Thursday, August 1, 2013 12:10 AM
To: Anthony Nadalin
Cc: Hannes Tschofenig; oauth mailing list
Subject: Re: [OAUTH-WG] Informal Dinner Discussion; Thursday @ 19:00

That's a 35 minute walk each way. Will MSFT be providing transportation?


On Thu, Aug 1, 2013 at 8:52 AM, Anthony Nadalin 
mailto:tony...@microsoft.com>> wrote:
How about http://www.zollpackhof.de/english/restaurant/terrassen.html


-Original Message-
From: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org> 
[mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On Behalf Of 
Hannes Tschofenig
Sent: Wednesday, July 31, 2013 6:15 AM
To: oauth mailing list
Subject: [OAUTH-WG] Informal Dinner Discussion; Thursday @ 19:00

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi all,

as mentioned during the OAuth WG meeting today we will meet for an informal 
discussion about the next steps in OAuth in the hotel lobby at 19:00 on 
Thursday.
We have not yet decided where to go.

Ciao
Hannes

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJR+Q3gAAoJEGhJURNOOiAtrpwH/AiHFCzwq+5niigfTB5n25pq
FxardCXE1cvsd/WVd5Kd1nzNNR9bgaGlMDDhsbPd0Ra//29S78UsVGOJBa5c2ji5
xDcpnwAaLruxfEbdrwKHqH6IWDlh6WJyCh/2jpMGeXmXSKUm52rrzVRc3qn1XYFU
Y2RDMhC2DgSjrauvxXO74IWJKVhIexr4bs/KoAqwvfEsD/RrIiwNeIq4FYJUgwtL
zjUVPzIBvkv+Fg716qCAgDL1+vP0kw6YC58JEkAXiIjuZMrdrYS6Llm4hA3Pmuz8
fWrHjNOjKZbHUlb9nwoNaViVLb4x7ny81NdYThZtsEvrI9U0DsYVnwl0urhvSDQ=
=1GDF
-END PGP SIGNATURE-
___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth





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

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

Re: [OAUTH-WG] Informal Dinner Discussion; Thursday @ 19:00

[Anthony Nadalin]

Life is full of surprises and bountiful experiences

From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Thursday, August 1, 2013 12:35 AM
To: Anthony Nadalin
Cc: Hannes Tschofenig; oauth mailing list
Subject: Re: [OAUTH-WG] Informal Dinner Discussion; Thursday @ 19:00

I wasn't concerned about the exercise but rather with having to spend that much 
more time with you.

On Thu, Aug 1, 2013 at 9:14 AM, Anthony Nadalin 
mailto:tony...@microsoft.com>> wrote:
It's called exercise or take the S7, this also give you a culture experience of 
getting away from the hotel and IETF crowd.

From: Brian Campbell 
[mailto:bcampb...@pingidentity.com<mailto:bcampb...@pingidentity.com>]
Sent: Thursday, August 1, 2013 12:10 AM
To: Anthony Nadalin
Cc: Hannes Tschofenig; oauth mailing list
Subject: Re: [OAUTH-WG] Informal Dinner Discussion; Thursday @ 19:00

That's a 35 minute walk each way. Will MSFT be providing transportation?

On Thu, Aug 1, 2013 at 8:52 AM, Anthony Nadalin 
mailto:tony...@microsoft.com>> wrote:
How about http://www.zollpackhof.de/english/restaurant/terrassen.html


-Original Message-
From: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org> 
[mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On Behalf Of 
Hannes Tschofenig
Sent: Wednesday, July 31, 2013 6:15 AM
To: oauth mailing list
Subject: [OAUTH-WG] Informal Dinner Discussion; Thursday @ 19:00

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi all,

as mentioned during the OAuth WG meeting today we will meet for an informal 
discussion about the next steps in OAuth in the hotel lobby at 19:00 on 
Thursday.
We have not yet decided where to go.

Ciao
Hannes

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJR+Q3gAAoJEGhJURNOOiAtrpwH/AiHFCzwq+5niigfTB5n25pq
FxardCXE1cvsd/WVd5Kd1nzNNR9bgaGlMDDhsbPd0Ra//29S78UsVGOJBa5c2ji5
xDcpnwAaLruxfEbdrwKHqH6IWDlh6WJyCh/2jpMGeXmXSKUm52rrzVRc3qn1XYFU
Y2RDMhC2DgSjrauvxXO74IWJKVhIexr4bs/KoAqwvfEsD/RrIiwNeIq4FYJUgwtL
zjUVPzIBvkv+Fg716qCAgDL1+vP0kw6YC58JEkAXiIjuZMrdrYS6Llm4hA3Pmuz8
fWrHjNOjKZbHUlb9nwoNaViVLb4x7ny81NdYThZtsEvrI9U0DsYVnwl0urhvSDQ=
=1GDF
-END PGP SIGNATURE-
___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth





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


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

Re: [OAUTH-WG] OX needs Dynamic Registration: please don't remove!

[Anthony Nadalin]

gt; 
>>> It seems that some people are dissatisfied with RFC 6749 and would like to 
>>> see changes like removing implicit flows.
>>> 
>>> The current Dynamic registration spec deals with the current state of 
>>> OAuth.   If the WG decides to do a OAuth 3 that fully supports assertions 
>>> and ditches secrets I would be OK with that. 
>>> However lets not cripple what we have as a standard now by crating dynamic 
>>> registration that can only be fully implemented  in a future version of 
>>> OAuth.
>>> 
>>> Some people want/need a client registration API now.  It is clearly a 
>>> missing part of an entire OAuth system.   
>>> Supporting existing OAuth while minimizing state at the AS is something I 
>>> support, waiting for a OAuth redesign is not in my opinion a reasonable 
>>> medium term goal.
>>> 
>>> John B.
>>> 
>>> 
>>> On 2013-08-14, at 11:47 PM, Phil Hunt  wrote:
>>> 
>>>> I am saying a bearer token is better than a password for the service 
>>>> provider as Hannes explains. 
>>>> 
>>>> Phil
>>>> 
>>>> On 2013-08-14, at 19:42, Nat Sakimura  wrote:
>>>> 
>>>>> Right. A Bearer Token does not have to be a shared secret. It may have 
>>>>> some structure that allows the server to validate it statelessly, e.g. 
>>>>> JWS-JWT. 
>>>>> 
>>>>> =nat via iPhone
>>>>> 
>>>>> Aug 14, 2013 15:32、Hannes Tschofenig  のメッセージ:
>>>>> 
>>>>>> George is correct with his statements. There is, however, a difference 
>>>>>> between a shared secret and an assertion as Phil pointed out. For the 
>>>>>> assertion the server does not need to maintain state on a per-client 
>>>>>> basis. On the other hand since the client secret isn't really used in 
>>>>>> the classical sense of a password either but rather as a "cookie" (if 
>>>>>> used in the style of Section 2.3.1 of RFC6749) one could easy apply the 
>>>>>> concept of stateless tokens to them:
>>>>>> http://tools.ietf.org/html/draft-rescorla-stateless-tokens-01
>>>>>> 
>>>>>> 
>>>>>> On 08/13/2013 07:21 PM, George Fletcher wrote:
>>>>>>> Hi Phil,
>>>>>>> 
>>>>>>> I'm sorry for not following completely. Some questions inline...
>>>>>>> 
>>>>>>> On 8/13/13 11:00 AM, Phil Hunt wrote:
>>>>>>>> Dyn reg and the scim reg variant depend too much/biased towards 
>>>>>>>> passwords expressed as client secrets.
>>>>>>> I'm not sure what you mean in regards to "client secrets". There 
>>>>>>> are
>>>>>>> OAuth2 bearer tokens that need to be protected because they are 
>>>>>>> bearer tokens. That said, there is nothing in the spec that 
>>>>>>> requires these to be opaque blobs vs signed tokens. So both the 
>>>>>>> "Initial Access Token" and the "Registration Access Token" can 
>>>>>>> be signed tokens. However, the client still has to protect them 
>>>>>>> as if they were a "secret" because they are a bearer token and 
>>>>>>> can be replayed. So it's the same amount of work on the client either 
>>>>>>> way.
>>>>>>> 
>>>>>>>> 
>>>>>>>> A signed token approach has many advantages for service 
>>>>>>>> providers like not having to maintain a secure database of 
>>>>>>>> secrets/passwords.
>>>>>>> If the concern here is the amount of data the Authorization 
>>>>>>> Server has to store to manage these clients, then the current 
>>>>>>> spec doesn't preclude using a "signed token". Both OAuth2 bearer 
>>>>>>> tokens identified in the current spec can be signed tokens.
>>>>>>>> 
>>>>>>>> Finally issuing both a client secret and registration token is 
>>>>>>>> costly and confusing to client developers.  I relented somewhat 
>>>>>>>> when I realized kerberos does this--but i still feel it is a 
>>>>>>>> bad design at cloud scale.
>>>>>>&g

Re: [OAUTH-WG] OX needs Dynamic Registration: please don't remove!

[Anthony Nadalin]

lt;mailto:jric...@mitre.org><mailto:jric...@mitre.org>> wrote:



The spec doesn't care where you deploy at -- if URL space is at a

premium for you, then switch based on input parameters and other

things. And you're still not clear on which "secrets" you're ta

 king

issue with.



-- Justin



On 08/13/2013 10:46 AM, Anthony Nadalin wrote:



#1, its yet another endpoint to have to manage secrets at, yes this

is an OAuth item but it’s growing out of control, we are trying to

move away from secrets and management of these endpoints as this

would be just another one we have to support, monitor and report on



#2 yes, 1 physical endpoint acting as multiple authorization servers



*From:*George Fletcher [mailto:gffle...@aol.com]

*Sent:* Tuesday, August 13, 2013 7:40 AM

*To:* Anthony Nadalin

*Cc:* m...@gluu.org<mailto:m...@gluu.org>; Justin Richer; 
oauth@ietf.org<mailto:oauth@ietf.org>

*Subject:* Re: [OAUTH-WG] OX needs Dynamic Registration: please

don't remove!



Hi Tony,



Could you please explain a little more?



For issue 1:

* Which "secret" are you refe

 rring

to? OAuth2 by default allows for

an optional client_secret. I'm not sure why this would cause

management issues? Or are you referring to the "Registration Access

Token"?

* Why is a separate endpoint an issue? Any client is going to be

talking to more than just the /authorize and /token endpoints anyway

so I'm confused regarding the extra complexity?



For issue 2:

* What specifically do you mean by "multi-tenant"? Is this one

server acting on behalf of multiple tenants and so appearing as

multiple Authorization Servers?



Thanks,

George



[snip...]









OAuth mailing list

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

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



--









OAuth mailing list

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

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







OAuth mailing list

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

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





OAuth mailing list

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

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





OAuth mailing list

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

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







OAuth mailing list

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

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




___

OAuth mailing list

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

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

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

Re: [OAUTH-WG] OX needs Dynamic Registration: please don't remove!

[Anthony Nadalin]

en switch based on input parameters and other
things. And you're still not clear on which "secrets" you're ta

 king
issue with.

-- Justin

On 08/13/2013 10:46 AM, Anthony Nadalin wrote:

#1, its yet another endpoint to have to manage secrets at, yes this
is an OAuth item but it’s growing out of control, we are trying to
move away from secrets and management of these endpoints as this
would be just another one we have to support, monitor and report on

#2 yes, 1 physical endpoint acting as multiple authorization servers

*From:*George Fletcher [mailto:gffle...@aol.com]
*Sent:* Tuesday, August 13, 2013 7:40 AM
*To:* Anthony Nadalin
*Cc:* m...@gluu.org<mailto:m...@gluu.org>; Justin Richer; 
oauth@ietf.org<mailto:oauth@ietf.org>
*Subject:* Re: [OAUTH-WG] OX needs Dynamic Registration: please
don't remove!

Hi Tony,

Could you please explain a little more?

For issue 1:
* Which "secret" are you refe

 rring

to? OAuth2 by default allows for
an optional client_secret. I'm not sure why this would cause
management issues? Or are you referring to the "Registration Access
Token"?
* Why is a separate endpoint an issue? Any client is going to be
talking to more than just the /authorize and /token endpoints anyway
so I'm confused regarding the extra complexity?

For issue 2:
* What specifically do you mean by "multi-tenant"? Is this one
server acting on behalf of multiple tenants and so appearing as
multiple Authorization Servers?

Thanks,
George

[snip...]





OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

--




OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth





OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth



OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth



OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth





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

[OAUTH-WG] Dynamic Client Registration Requirements

[Anthony Nadalin]

Here are some of our requirements for Dynamic Client Registration as we work 
through the various proposals:

1. Stateless server
2. Code flow support
3. Implicit flow support
4. Multi-tenant  support (single endpoint, multiple services)
5. internationalization
6. simple provisioning schema with schema extensibility 
7. self-assertion 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Audience parameter in authorization flow

[Anthony Nadalin]

I think binding audience at registration time is to limiting as we see audience 
being on a per token request level and also see the audience being part of the 
restrictions for "act as" or "on behalf of" support 

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Hannes Tschofenig
Sent: Wednesday, August 21, 2013 9:41 AM
To: Phil Hunt
Cc: 
Subject: Re: [OAUTH-WG] Audience parameter in authorization flow

That's certainly true although the referenced document did not talk about the 
registration phase but rather about the time when the client talks to the 
authorization server to obtain an access token.

Maybe UMA has provided a story for this already...

On 08/21/2013 06:35 PM, Phil Hunt wrote:
> This could be bound up in the client registration process since oauth clients 
> don't authorize for random "targets".
>
> Phil
>
> @independentid
> www.independentid.com
> phil.h...@oracle.com
>
>
>
>
>
>
>
> On 2013-08-21, at 9:30 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" 
>  wrote:
>
>> Hi Sergey,
>>
>> The idea of the audience was to provide a way for the client to indicate the 
>> resource server it wants to talk to explicitly rather than overloading the 
>> scope field. We certainly need that capability for the MAC token work.
>>
>> The audience information is provided when the client interacts with the AS.
>>
>> Ciao
>> Hannes
>>
>>
>>> -Original Message-
>>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On 
>>> Behalf Of ext Sergey Beryozkin
>>> Sent: Sunday, August 18, 2013 6:32 PM
>>> To: 
>>> Subject: [OAUTH-WG] Audience parameter in authorization flow
>>>
>>> Hi Hannes, All,
>>>
>>> Regarding [1], where would you expect an audience parameter be 
>>> provided during the authorization flow ?
>>>
>>> It appears to me it should be provided during the initial redirect 
>>> (similarly to a parameter like redirect_uri).
>>>
>>> Also, would it make sense to support pre-registered audience values, 
>>> example, a client registers and specifies an audience during the 
>>> registration ?
>>>
>>> Thanks, Sergey
>>>
>>> [1] http://tools.ietf.org/html/draft-tschofenig-oauth-audience-00
>>> ___
>>> 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] Dynamic Client Registration Requirements

[Anthony Nadalin]

4. So when registration takes place it may be at a single endpoint, but that 
endpoint has to have enough info to figure out which virtual registration point 
it need to deal with, much like what we had to do in SCIM to support 
multi-tenants
5. any info sent to the registration endpoint need a way to figure out 
internationalization 
6. What has been proposed does not take into account the data model difference 
that you can have with schema, having the ability to replace schema/add 
elements is not schema extensibility, come over to the SCIM discussions 
7. It is verified by the person asserting it, so yes you have the concept.

-Original Message-
From: Tschofenig, Hannes (NSN - FI/Espoo) [mailto:hannes.tschofe...@nsn.com] 
Sent: Wednesday, August 21, 2013 9:28 AM
To: Anthony Nadalin; oauth mailing list
Subject: RE: Dynamic Client Registration Requirements

Hi Tony, 

Could you expand a little bit on those issues: 

> 4. Multi-tenant  support (single endpoint, multiple services)

What does multiple services mean here in the context of dynamic client 
registration? 

> 5. Internationalization

Where do you see internationalization play a role here? 

> 6. simple provisioning schema with schema extensibility

I guess all of the schemas we use are extensible. Is there something in 
particular you worry about? 

> 7. self-assertion

I guess this refers to the ability of the client to upload configuration that 
has not been verified by anyone, i.e., the client asserts this information by 
itself. Right? 

Ciao
Hannes

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

Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Thu 22 Aug, 2pm PDT: Conference Bridge Details -- Correction!

[Anthony Nadalin]

Phil, this just brings me back to the question, "why are we doing this in 
OAuth" ? Configuration endpoint (nothing to do with OAuth), Registration 
Endpoint (too complicated, goes beyond the bounds of OAuth), why not just a 
stateless and state full registration message and that's it?

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Phil 
Hunt
Sent: Thursday, August 22, 2013 12:23 PM
To: Tschofenig, Hannes (NSN - FI/Espoo)
Cc: oauth mailing list
Subject: Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Thu 22 
Aug, 2pm PDT: Conference Bridge Details -- Correction!

I have attached a PDF including some of my thoughts, concerns, and suggestions 
for the upcoming meeting.

Phil

@independentid
www.independentid.com
phil.h...@oracle.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Dynamic Client Registration Conference Call - Meeting Minutes (22. Aug)

[Anthony Nadalin]

>I believe Tony commented that "if something is optional, it means that ALL 
>servers everywhere have to support it". I don't understand that - the 
>requirement for servers to ignore (i.e., don't throw an error or fall
over) if a client sends over a parameter it doesn't understand has always been 
part of the core OAuth 2.0 spec. It's not a new idea.

So servers have to code to prevent unwanted behavior from happening, so the 
more that is in the spec that is optional that the server does not want to 
support the more the server side has to deal with failing, ignoring, etc. It 
makes more sense to chunk this up into a basic registration message and 
response and then extensions for all the stuff that that go beyond the simple 
registration process. OIDC can't just pick this up and use it as is, there are 
still specific requirements that OIDC needs beyond this and different from this 
proposal, so the I believe that we could get agreement on the basic 
registration messages and let the other groups do the specific extensions they 
need. 

As I have stated most of the dynamic registration draft goes beyond the scope 
of this WG dealing with client configuration and management. We have stayed 
well away from client authentication methods and we should stay well away from 
client configuration and management.

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Anganes, Amanda L
Sent: Friday, August 23, 2013 5:46 AM
To: Hannes Tschofenig; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Dynamic Client Registration Conference Call - Meeting 
Minutes (22. Aug)

Thanks for the notes, Hannes.

I didn't speak up on the call at all because it honestly left me a bit 
confused. For the first 3/4 or so I was trying to figure out what the problem 
was that everyone was fighting about. Phil, Tony, and others seemed to be 
pointing out that "in all of these cases that we can tell you about, it doesn't 
make sense to do DynReg". That is fine. That's not a problem; that just 
reflects the fact that there are different use cases out there that may not 
need this OPTIONAL part of the spec suite.

After that there seemed to be some consensus (at least among those that were 
bringing up the original complaints) that folks would like to see a smaller 
core document, with all of the optional parts removed to one or more 
extensions. I'll grant that the DynReg draft has gotten long and there are a 
lot of optional pieces. Maybe it makes sense to break it out; at the very least 
I think it's worth trying. Perhaps more of the WG would accept it if that was 
the case.

I believe Tony commented that "if something is optional, it means that ALL 
servers everywhere have to support it". I don't understand that - the 
requirement for servers to ignore (i.e., don't throw an error or fall
over) if a client sends over a parameter it doesn't understand has always been 
part of the core OAuth 2.0 spec. It's not a new idea.

There was also a comment that the WG doesn't have a lot of experience with this 
domain. That's true, but the experience the WG *does* have is with the UMA and 
OIDC use cases, which directly fed into the current draft.
DynReg v14 is sufficient for the two major classes of *real*, deployed and 
under development, non-hypothetical use cases that we know of today. We can't 
loose sight of this fact.

If there is something missing from the current draft, or something present that 
disallows a particular requirement, I'd ask the other WG members to please 
present those requirements and problems clearly so that we can discuss them. So 
far I haven't seen anything concrete in this area. I've heard a lot of 
contention and fighting but I can't make out what the actual problem statement 
is. Phil's software statements/assertions seems to fit well as an extension; 
it's not prohibited by anything existing in the draft. 

*apologies if I misattributed comments; I can recognize most of the voices that 
were on the call but not all of them.

--Amanda





On 8/23/13 4:24 AM, "Hannes Tschofenig"  wrote:

>Thank you all for joining yesterday's conference call. I took some 
>notes during the call.
>
> Meeting Minutes 
>
>Participants:
>- William Kim
>- John Bradley
>- Antonio Sanso
>- Mike Jones
>- Phil Hunt
>- Justin Richer
>- Hannes Tschofenig
>- Derek Atkins
>- Amanda Anganes
>- Morteza Ansari
>- Brian Campbell
>- Thomas Hardjono
>- Prateek Mishra
>- George Fletcher
>- Tony Nadalin
>
>Minutes
>
>Justin started with a discussion about what is described in Section 1.3 
>of the protocol specification and Appendix B describes the use cases.
>
>Dynamic client registration is one way to introduce a client to an 
>authorization server

Re: [OAUTH-WG] Refactoring Dynamic Registration

[Anthony Nadalin]

Thanks for splitting this and making it simple.

It's unclear if the server must send the metadata back in same form/order/ as 
sent, that is, does client expect to get back only what was sent with what 
server values will be or can client deal with defaults that the sever sets 

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Richer, Justin P.
Sent: Tuesday, August 27, 2013 7:06 AM
To: oauth mailing list
Subject: [OAUTH-WG] Refactoring Dynamic Registration

After last week's design team call, at Derek's suggestion, I took time today to 
refactor the Dynamic Registration draft into two pieces: "core" and 
"management". The former contains the definition of the Registration Endpoint 
and the semantics surrounding that, the latter contains the Client 
Configuration Endpoint as well as the "non-essential" client metadata 
parameters.  

I did this refactoring with an axe, so there are almost certainly bits and 
pieces that are in the wrong document. In particular, I've kept the use cases 
in the "core" document even though they reference concepts and constructs 
defined in the "management" spec. This way people that don't want to deal with 
a configuration management API can implement just the "core" registration spec 
and call it a day, while people who want to have full lifecycle control can do 
the "management" spec on top of it. This does increase the optionality by 
making the client configuration endpoint parameters optional, but that's the 
tradeoff for having things cut this way.

You can read both the specs here:

http://tools.ietf.org/html/draft-richer-oauth-dyn-reg-core-00

http://tools.ietf.org/html/draft-richer-oauth-dyn-reg-management-00

I've uploaded these as individual submissions for now. If the working group 
decides to move forward with this refactoring, I expect both documents to move 
in tandem through the RFC approval process.

 -- Justin
___
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] Refactoring Dynamic Registration

[Anthony Nadalin]

Understand all that  but does not say what the response will be on an 
additional parameter that the server does not understand,  does the parameter 
come back with a null, or is the parameter omitted on response ?

-Original Message-
From: Justin Richer [mailto:jric...@mitre.org] 
Sent: Tuesday, August 27, 2013 11:12 AM
To: Anthony Nadalin
Cc: oauth mailing list
Subject: Re: Refactoring Dynamic Registration

A JSON object is not order dependent by definition, so order of elements 
doesn't matter.

In the section on client metadata and the client information response, it's 
stated that the server can:

1) Override a client's requested values and replace with its own
2) Insert a new field/value that the client didn't supply (effectively a server 
default)
3) Restrict the value of a given field

Therefore, clients MUST deal with whatever kinds of extra JSON a server might 
respond (so long as it's a valid JSON object). Thankfully, since this is JSON 
and not a schema-based XML format, this is trivial to implement for the client.

If you have suggestions about how to word this better, please submit text.

  -- Justin

On 08/27/2013 01:20 PM, Anthony Nadalin wrote:
> Thanks for splitting this and making it simple.
>
> It's unclear if the server must send the metadata back in same 
> form/order/ as sent, that is, does client expect to get back only what 
> was sent with what server values will be or can client deal with 
> defaults that the sever sets
>
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
> Richer, Justin P.
> Sent: Tuesday, August 27, 2013 7:06 AM
> To: oauth mailing list
> Subject: [OAUTH-WG] Refactoring Dynamic Registration
>
> After last week's design team call, at Derek's suggestion, I took time today 
> to refactor the Dynamic Registration draft into two pieces: "core" and 
> "management". The former contains the definition of the Registration Endpoint 
> and the semantics surrounding that, the latter contains the Client 
> Configuration Endpoint as well as the "non-essential" client metadata 
> parameters.
>
> I did this refactoring with an axe, so there are almost certainly bits and 
> pieces that are in the wrong document. In particular, I've kept the use cases 
> in the "core" document even though they reference concepts and constructs 
> defined in the "management" spec. This way people that don't want to deal 
> with a configuration management API can implement just the "core" 
> registration spec and call it a day, while people who want to have full 
> lifecycle control can do the "management" spec on top of it. This does 
> increase the optionality by making the client configuration endpoint 
> parameters optional, but that's the tradeoff for having things cut this way.
>
> You can read both the specs here:
>
> http://tools.ietf.org/html/draft-richer-oauth-dyn-reg-core-00
>
> http://tools.ietf.org/html/draft-richer-oauth-dyn-reg-management-00
>
> I've uploaded these as individual submissions for now. If the working group 
> decides to move forward with this refactoring, I expect both documents to 
> move in tandem through the RFC approval process.
>
>   -- Justin
> ___
> 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] Refactoring Dynamic Registration

[Anthony Nadalin]

This is a better explanation that what is in the current document, as this will 
become an interop problem that the clients need to deal with and not sure how 
the client is going to know how to deal with all these permutations, there 
should be a recommended action.

-Original Message-
From: Justin Richer [mailto:jric...@mitre.org] 
Sent: Tuesday, August 27, 2013 11:34 AM
To: Anthony Nadalin
Cc: oauth mailing list
Subject: Re: Refactoring Dynamic Registration

If the server does not understand a parameter (and by this, remember, we mean a 
field in the JSON object, not a query parameter), it can accept it, ignore it, 
replace it with a default value, or return an error.

Think of it in terms of the data model: The client has some model of what 
information it knows about, and the server's got some internal model of what a 
"registered client" is, and the client information response reflects the 
*server's* model of a client. Ultimately, the client is making a registration 
request, the server is returning the reality of what was actually registered. 
The client MUST defer to the server's values in these cases. If the server 
returns a value that the client doesn't know about (and doesn't know what to do 
with), the client will ignore that.

If the server's ignoring the parameter completely (which I think will be the 
common implementation), the server will just leave it out of the returned 
object entirely. That's what our server does if you send it some parameter that 
it doesn't know or care about -- it will safely ignore the field when it saves 
the object and echoes the configuration back. I'll here note that we didn't do 
anything special to make that happen, that's pretty much out of the box JSON 
library behavior in my experience.

The server could return a null value, or replace it with some default value 
that the server likes better. If the server's data model is somehow normalized 
and wants to take and remember *whatever* the client sends, it can echo back 
what the client sent. I don't think that's going to be very common in practice 
though, and clients need to be prepared to take back whatever the server 
dictates. Since the server is the final authority of what's attached to a given 
client ID, this is the appropriate model.

  -- Justin

On 08/27/2013 02:22 PM, Anthony Nadalin wrote:
> Understand all that  but does not say what the response will be on an 
> additional parameter that the server does not understand,  does the parameter 
> come back with a null, or is the parameter omitted on response ?
>
> -Original Message-
> From: Justin Richer [mailto:jric...@mitre.org]
> Sent: Tuesday, August 27, 2013 11:12 AM
> To: Anthony Nadalin
> Cc: oauth mailing list
> Subject: Re: Refactoring Dynamic Registration
>
> A JSON object is not order dependent by definition, so order of elements 
> doesn't matter.
>
> In the section on client metadata and the client information response, it's 
> stated that the server can:
>
> 1) Override a client's requested values and replace with its own
> 2) Insert a new field/value that the client didn't supply (effectively 
> a server default)
> 3) Restrict the value of a given field
>
> Therefore, clients MUST deal with whatever kinds of extra JSON a server might 
> respond (so long as it's a valid JSON object). Thankfully, since this is JSON 
> and not a schema-based XML format, this is trivial to implement for the 
> client.
>
> If you have suggestions about how to word this better, please submit text.
>
>-- Justin
>
> On 08/27/2013 01:20 PM, Anthony Nadalin wrote:
>> Thanks for splitting this and making it simple.
>>
>> It's unclear if the server must send the metadata back in same 
>> form/order/ as sent, that is, does client expect to get back only 
>> what was sent with what server values will be or can client deal with 
>> defaults that the sever sets
>>
>> -Original Message-
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
>> Richer, Justin P.
>> Sent: Tuesday, August 27, 2013 7:06 AM
>> To: oauth mailing list
>> Subject: [OAUTH-WG] Refactoring Dynamic Registration
>>
>> After last week's design team call, at Derek's suggestion, I took time today 
>> to refactor the Dynamic Registration draft into two pieces: "core" and 
>> "management". The former contains the definition of the Registration 
>> Endpoint and the semantics surrounding that, the latter contains the Client 
>> Configuration Endpoint as well as the "non-essential" client metadata 
>> parameters.
>>
>> I did this refactoring with an axe, so there are almost c

Re: [OAUTH-WG] Refactoring Dynamic Registration

[Anthony Nadalin]

I believe the 
http://tools.ietf.org/html/draft-richer-oauth-dyn-reg-management-00 is out of 
scope for this WG and needs to go to the APPS area since we don't deal with 
other OAuth management issues

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Richer, Justin P.
Sent: Tuesday, August 27, 2013 7:06 AM
To: oauth mailing list
Subject: [OAUTH-WG] Refactoring Dynamic Registration

After last week's design team call, at Derek's suggestion, I took time today to 
refactor the Dynamic Registration draft into two pieces: "core" and 
"management". The former contains the definition of the Registration Endpoint 
and the semantics surrounding that, the latter contains the Client 
Configuration Endpoint as well as the "non-essential" client metadata 
parameters.  

I did this refactoring with an axe, so there are almost certainly bits and 
pieces that are in the wrong document. In particular, I've kept the use cases 
in the "core" document even though they reference concepts and constructs 
defined in the "management" spec. This way people that don't want to deal with 
a configuration management API can implement just the "core" registration spec 
and call it a day, while people who want to have full lifecycle control can do 
the "management" spec on top of it. This does increase the optionality by 
making the client configuration endpoint parameters optional, but that's the 
tradeoff for having things cut this way.

You can read both the specs here:

http://tools.ietf.org/html/draft-richer-oauth-dyn-reg-core-00

http://tools.ietf.org/html/draft-richer-oauth-dyn-reg-management-00

I've uploaded these as individual submissions for now. If the working group 
decides to move forward with this refactoring, I expect both documents to move 
in tandem through the RFC approval process.

 -- Justin
___
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] Refactoring Dynamic Registration

[Anthony Nadalin]

Well, that is just one minor nit and not sure that this is the proper base to 
start with for the core, I was only trying to understand the intent of the 
specification.  There is the fundamental issue of relationship (endpoint/ API 
publisher and with whom the client is trying to register with and how the 
registration data is organized /represented as each server has to deal with all 
sorts of clients.

-Original Message-
From: Justin Richer [mailto:jric...@mitre.org] 
Sent: Tuesday, August 27, 2013 11:42 AM
To: Anthony Nadalin
Cc: oauth mailing list
Subject: Re: Refactoring Dynamic Registration

OK, please submit text.

  -- Justin


On 08/27/2013 02:38 PM, Anthony Nadalin wrote:
> This is a better explanation that what is in the current document, as this 
> will become an interop problem that the clients need to deal with and not 
> sure how the client is going to know how to deal with all these permutations, 
> there should be a recommended action.
>
> -Original Message-
> From: Justin Richer [mailto:jric...@mitre.org]
> Sent: Tuesday, August 27, 2013 11:34 AM
> To: Anthony Nadalin
> Cc: oauth mailing list
> Subject: Re: Refactoring Dynamic Registration
>
> If the server does not understand a parameter (and by this, remember, we mean 
> a field in the JSON object, not a query parameter), it can accept it, ignore 
> it, replace it with a default value, or return an error.
>
> Think of it in terms of the data model: The client has some model of what 
> information it knows about, and the server's got some internal model of what 
> a "registered client" is, and the client information response reflects the 
> *server's* model of a client. Ultimately, the client is making a registration 
> request, the server is returning the reality of what was actually registered. 
> The client MUST defer to the server's values in these cases. If the server 
> returns a value that the client doesn't know about (and doesn't know what to 
> do with), the client will ignore that.
>
> If the server's ignoring the parameter completely (which I think will be the 
> common implementation), the server will just leave it out of the returned 
> object entirely. That's what our server does if you send it some parameter 
> that it doesn't know or care about -- it will safely ignore the field when it 
> saves the object and echoes the configuration back. I'll here note that we 
> didn't do anything special to make that happen, that's pretty much out of the 
> box JSON library behavior in my experience.
>
> The server could return a null value, or replace it with some default value 
> that the server likes better. If the server's data model is somehow 
> normalized and wants to take and remember *whatever* the client sends, it can 
> echo back what the client sent. I don't think that's going to be very common 
> in practice though, and clients need to be prepared to take back whatever the 
> server dictates. Since the server is the final authority of what's attached 
> to a given client ID, this is the appropriate model.
>
>-- Justin
>
> On 08/27/2013 02:22 PM, Anthony Nadalin wrote:
>> Understand all that  but does not say what the response will be on an 
>> additional parameter that the server does not understand,  does the 
>> parameter come back with a null, or is the parameter omitted on response ?
>>
>> -Original Message-
>> From: Justin Richer [mailto:jric...@mitre.org]
>> Sent: Tuesday, August 27, 2013 11:12 AM
>> To: Anthony Nadalin
>> Cc: oauth mailing list
>> Subject: Re: Refactoring Dynamic Registration
>>
>> A JSON object is not order dependent by definition, so order of elements 
>> doesn't matter.
>>
>> In the section on client metadata and the client information response, it's 
>> stated that the server can:
>>
>> 1) Override a client's requested values and replace with its own
>> 2) Insert a new field/value that the client didn't supply 
>> (effectively a server default)
>> 3) Restrict the value of a given field
>>
>> Therefore, clients MUST deal with whatever kinds of extra JSON a server 
>> might respond (so long as it's a valid JSON object). Thankfully, since this 
>> is JSON and not a schema-based XML format, this is trivial to implement for 
>> the client.
>>
>> If you have suggestions about how to word this better, please submit text.
>>
>> -- Justin
>>
>> On 08/27/2013 01:20 PM, Anthony Nadalin wrote:
>>> Thanks for splitting this and making it simple.
>>>
>>> It's unclear if the server must send the metadata back in 

Re: [OAUTH-WG] Fwd: New Version Notification for draft-hunt-oauth-v2-user-a4c-01.txt

[Anthony Nadalin]

So these are not authentication context. It does more harm than good to have an 
extensible IANA registry of values that have no discernable meaning, with the 
ISO 29115 values you can go an acutually understand the values and have 
something to potentially interop on

From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of John 
Bradley
Sent: Tuesday, August 27, 2013 4:28 PM
To: Phil Hunt
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for 
draft-hunt-oauth-v2-user-a4c-01.txt

It is better.  We need to talk about what you have done with "min_alv" vs "acr" 
from  connect which is extensible via a IANA registry of Authentication 
contexts.

If it came down to reserving the strings 1 2 3 4 for the ISO29115 reference 
that could probably be arranged.

I don't know that throwing an error if the min can't be supported is the 
correct thing.  We had a lot of debate about that and decided that returning 
the actual acr and letting the client decide was better than an error.

Also remember that the request is not signed so someone could modify it to 
remove min_alv and spoof a RP that expects all positive results to meet what it 
asked for.

More discussion on min_alv is required.

John B.

On 2013-08-27, at 12:52 PM, Phil Hunt 
mailto:phil.h...@oracle.com>> wrote:


FYI.  Based on feedback from Berlin, Tony and I have revised the draft to 
include:

* Alignment with OpenID Connect (using id_token)
* Always returns a JWT
* Minimum assertion level on request
* Return information about the type of authentication performed

Thanks for your input.

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
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-v2-user-a4c-01.txt
Date: 27 August, 2013 8:56:45 AM PDT
To: Phil Hunt mailto:phil.h...@yahoo.com>>, Anthony 
Nadalin mailto:tony...@microsoft.com>>, Tony Nadalin 
mailto:tony...@microsoft.com>>


A new version of I-D, draft-hunt-oauth-v2-user-a4c-01.txt
has been successfully submitted by Phil Hunt and posted to the
IETF repository.

Filename: draft-hunt-oauth-v2-user-a4c
Revision: 01
Title:OAuth 2.0 User Authentication and Consent For Clients
Creation date: 2013-08-27
Group: Individual Submission
Number of pages: 10
URL: 
http://www.ietf.org/internet-drafts/draft-hunt-oauth-v2-user-a4c-01.txt
Status:  http://datatracker.ietf.org/doc/draft-hunt-oauth-v2-user-a4c
Htmlized:http://tools.ietf.org/html/draft-hunt-oauth-v2-user-a4c-01
Diff:
http://www.ietf.org/rfcdiff?url2=draft-hunt-oauth-v2-user-a4c-01

Abstract:
  This specification defines a new OAuth2 endpoint that enables user
  authentication session and consent information to be shared with
  client applications.




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<http://tools.ietf.org/>.

The IETF Secretariat

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

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

Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Wed 28 Aug, 2pm PDT: Conference Bridge Details

[Anthony Nadalin]

>Therefore I once again call for the WG to finish the current dynamic 
>registration spec *AND* pursue the assertion based process that Phil's talking 
>about. They're not mutually exclusive, let's please stop talking 

I see no reason to continue to push finish the current specification when there 
are so many discussions/issues going on as discussions will only lead to better 
specifications that folks can actually implement and use.

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Justin Richer
Sent: Wednesday, August 28, 2013 8:42 AM
To: Phil Hunt
Cc: oauth mailing list
Subject: Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Wed 28 
Aug, 2pm PDT: Conference Bridge Details

Except for the cases where you want step 1 to happen in band. To me, that is a 
vitally and fundamentally important use case that we can't disregard, and we 
must have a solution that can accommodate that. The notions of "publisher" and 
"product" fade very quickly once you get outside of the software vendor world.

This is, of course, not to stand in the way of other solutions or approaches 
(such as something assertion based like you're after). It's not a 
one-or-the-other proposition, especially when there are mutually exclusive 
aspects of each.

Therefore I once again call for the WG to finish the current dynamic 
registration spec *AND* pursue the assertion based process that Phil's talking 
about. They're not mutually exclusive, let's please stop talking about them 
like they are.

  -- Justin

On 08/28/2013 11:17 AM, Phil Hunt wrote:
> Sorry. I meant also to say i think there are 2 registration steps.
>
> 1. Software registration/approval. This often happens out of band. But in 
> this step policy is defined that approves software for use. Many of the reg 
> params are known here.
>
> Federation techniques come into play as trust approvals can be based on 
> developer, product or even publisher.
>
> 2. Each instance associates in a stateless way. Only clients that need 
> credential rotation need more.
>
> Phil
>
> On 2013-08-28, at 8:04, Phil Hunt  wrote:
>
>> I have a conflict I cannot get out of for 2pacific.
>>
>> I think a certificate based approach is going to simplify exchanges in all 
>> cases. I encourage the group to explore the concept on the call.
>>
>> I am not sure breaking dyn reg up helps. It creates yet another option. I 
>> would like to explore how federation concept in software statements can help 
>> with facilitating association and making many reg stateless.
>>
>> Phil
>>
>> On 2013-08-28, at 5:43, "Tschofenig, Hannes (NSN - FI/Espoo)" 
>>  wrote:
>>
>>> Here are the conference bridge / Webex details for the call today.
>>> We are going to complete the use case discussions from last time 
>>> (Phil wasn't able to walk through all slides). Justin was also able 
>>> to work out a strawman proposal based on the discussions last week 
>>> and we will have a look at it to see whether this is a suitable 
>>> compromise. Here is Justin's mail, in case you have missed it: 
>>> http://www.ietf.org/mail-archive/web/oauth/current/msg12036.html
>>>
>>> Phil, please feel free to make adjustments to your slides given the 
>>> Justin's recent proposal.
>>>
>>> Topic: OAuth Dynamic Client Registration
>>> Date: Wednesday, August 28, 2013
>>> Time: 2:00 pm, Pacific Daylight Time (San Francisco, GMT-07:00) 
>>> Meeting Number: 703 230 586 Meeting Password: oauth
>>>
>>> ---
>>> To join the online meeting
>>> ---
>>> 1. Go to 
>>> https://nsn.webex.com/nsn/j.php?ED=269567657&UID=0&PW=NNTI1ZWQzMDJk&;
>>> RT=MiM0 2. Enter your name and email address.
>>> 3. Enter the meeting password: oauth 4. Click "Join Now".
>>>
>>> To view in other time zones or languages, please click the link:
>>> https://nsn.webex.com/nsn/j.php?ED=269567657&UID=0&PW=NNTI1ZWQzMDJk&;
>>> ORT=MiM0
>>>
>>> To add this meeting to your calendar program (for example Microsoft 
>>> Outlook), click this link:
>>> https://nsn.webex.com/nsn/j.php?ED=269567657&UID=0&ICS=MI&LD=1&RD=2&;
>>> ST=1&SHA2=C6-AjLGvhdYjmpVdx75M6UsAwrNLMsequ5n95Gyv1R8=&RT=MiM0
>>>
>>> ---
>>> To join the teleconference only
>>> ---
>>> Global dial-in Numbers: http://www.nokiasiemensnetworks.com/nvc
>>> Conference Code: 944 910 5485
>>>
>>>
>>> ___
>>> 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@

Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Wed 28 Aug, 2pm PDT: Conference Bridge Details

[Anthony Nadalin]

So I guess we should have different specifications for different use cases to 
solve same requirements, I guess we should have done that we OAuth and not 
worked out common flows, patterns, parameters, etc. I have only seen 2-3 
respond to the implementation status, once again people should post if they:

1. have implemented this as is
2. plan on implementing as is
3. what use case they are solving
4. what modifications needed on top of this specification to actually solve use 
case

-Original Message-
From: Justin Richer [mailto:jric...@mitre.org] 
Sent: Wednesday, August 28, 2013 8:51 AM
To: Anthony Nadalin
Cc: Phil Hunt; oauth mailing list
Subject: Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Wed 28 
Aug, 2pm PDT: Conference Bridge Details

Except that folks are already actually implementing and using the spec, and 
that all of the discussions around different specs are pretty clearly pointing 
to different use cases and assumptions about the state of the world.

Your arguments are invalid.

  -- Justin

On 08/28/2013 11:49 AM, Anthony Nadalin wrote:
>> Therefore I once again call for the WG to finish the current dynamic 
>> registration spec *AND* pursue the assertion based process that 
>> Phil's talking about. They're not mutually exclusive, let's please 
>> stop talking
> I see no reason to continue to push finish the current specification when 
> there are so many discussions/issues going on as discussions will only lead 
> to better specifications that folks can actually implement and use.
>
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf 
> Of Justin Richer
> Sent: Wednesday, August 28, 2013 8:42 AM
> To: Phil Hunt
> Cc: oauth mailing list
> Subject: Re: [OAUTH-WG] Dynamic Client Registration Conference Call: 
> Wed 28 Aug, 2pm PDT: Conference Bridge Details
>
> Except for the cases where you want step 1 to happen in band. To me, that is 
> a vitally and fundamentally important use case that we can't disregard, and 
> we must have a solution that can accommodate that. The notions of "publisher" 
> and "product" fade very quickly once you get outside of the software vendor 
> world.
>
> This is, of course, not to stand in the way of other solutions or approaches 
> (such as something assertion based like you're after). It's not a 
> one-or-the-other proposition, especially when there are mutually exclusive 
> aspects of each.
>
> Therefore I once again call for the WG to finish the current dynamic 
> registration spec *AND* pursue the assertion based process that Phil's 
> talking about. They're not mutually exclusive, let's please stop talking 
> about them like they are.
>
>-- Justin
>
> On 08/28/2013 11:17 AM, Phil Hunt wrote:
>> Sorry. I meant also to say i think there are 2 registration steps.
>>
>> 1. Software registration/approval. This often happens out of band. But in 
>> this step policy is defined that approves software for use. Many of the reg 
>> params are known here.
>>
>> Federation techniques come into play as trust approvals can be based on 
>> developer, product or even publisher.
>>
>> 2. Each instance associates in a stateless way. Only clients that need 
>> credential rotation need more.
>>
>> Phil
>>
>> On 2013-08-28, at 8:04, Phil Hunt  wrote:
>>
>>> I have a conflict I cannot get out of for 2pacific.
>>>
>>> I think a certificate based approach is going to simplify exchanges in all 
>>> cases. I encourage the group to explore the concept on the call.
>>>
>>> I am not sure breaking dyn reg up helps. It creates yet another option. I 
>>> would like to explore how federation concept in software statements can 
>>> help with facilitating association and making many reg stateless.
>>>
>>> Phil
>>>
>>> On 2013-08-28, at 5:43, "Tschofenig, Hannes (NSN - FI/Espoo)" 
>>>  wrote:
>>>
>>>> Here are the conference bridge / Webex details for the call today.
>>>> We are going to complete the use case discussions from last time 
>>>> (Phil wasn't able to walk through all slides). Justin was also able 
>>>> to work out a strawman proposal based on the discussions last week 
>>>> and we will have a look at it to see whether this is a suitable 
>>>> compromise. Here is Justin's mail, in case you have missed it:
>>>> http://www.ietf.org/mail-archive/web/oauth/current/msg12036.html
>>>>
>>>> Phil, please feel free to make adjustments to your slides given the 
>>>> Justi

Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Wed 28 Aug, 2pm PDT: Conference Bridge Details

[Anthony Nadalin]

>Now maybe your way is the better way but why not let the market make that 
>decision?

So what is the hurry to get the dyn reg specification out the door, if we have 
the market data it will make the specification that much better. I agree that 
most of this can be done today w/o any additional specifications, that is what 
I question the complex, underspecified dyn reg specification that is being 
proposed.

From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Phil 
Hunt
Sent: Wednesday, August 28, 2013 9:55 AM
To: George Fletcher
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Wed 28 
Aug, 2pm PDT: Conference Bridge Details

That's what I'm trying to do. All I have been asking for is time to explore the 
spec and to see how it can impact and simplify dyn reg -- which I believe is a 
significant amount.  It would be pre-mature at this point to move Dyn Reg 
forward without exploring this.

I still believe dyn reg is over-specified because it assumes *every* cllient 
registration is different when in fact 99.9% of registrations are going to fall 
in clusters of client applications.  Much of the paramaters can be moved to 
step 1 of registration or at the least be bundled into the software assertion. 
Thus the reg endpoint only has to deal with truly instance specific details 
(e.g. like credential management).

I don't pre-clude that most of dyn reg may remain intact, but it seems clear 
there will be substantive breaking changes that simplify registration.

Phil

@independentid
www.independentid.com<http://www.independentid.com>
phil.h...@oracle.com<mailto:phil.h...@oracle.com>





On 2013-08-28, at 9:47 AM, George Fletcher 
mailto:gffle...@aol.com>> wrote:


So Phil... given that you can do all this today with the existing set of 
specifications... why not write the software statements/client assertion 
registration spec so that it meets your use case and deployment needs. I'd much 
rather have two straight forward ways to do something when the core use cases 
are so different than to try and munge everything into one and end up with 
unnecessary complexity in one or both of the solutions.

I see the use case you are trying to solve for as significantly different than 
the one I'm trying to solve for. Now maybe your way is the better way but why 
not let the market make that decision? We will not confuse developers by having 
two ways to do things as it will be very clear at the beginning of development 
which way is needed for their use case:)

Thanks,
George
On 8/28/13 12:41 PM, Phil Hunt wrote:

Yes. A client could pass the software statement *directly* as its client 
credential.  Which is one of the *simple* solutions. 8-)



The other case is where the client instance needs its own credential as George 
indicates.  In that case it could swap the statement for a unique client 
assertion.



Phil



@independentid

www.independentid.com<http://www.independentid.com/>

phil.h...@oracle.com<mailto:phil.h...@oracle.com>















On 2013-08-28, at 9:38 AM, Sergey Beryozkin 
<mailto:sberyoz...@gmail.com> wrote:



On 28/08/13 17:33, George Fletcher wrote:

So I understand that you'd rather that OAuth doesn't require a

client_secret and that's fine. However, I don't think we should impose

that thinking on the rest of the world who have already implemented it

and have it working and scaling without issues. If the core of this

discussion is around replacing client_id and client_secret with a

client_assertion then lets have that discussion separately and not bury

it in the dynamic registration discussion.



Could you not profile OAuth2 to support a flow that allows for retrieval

of access and refresh tokens using code + client_assertion? Doesn't seem

like that hard a profile and then the rest of this could fall out pretty

easily.



That is already supported AFAIK, something like



grant_type=authorization_code

&code=12345678

&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Asaml2-bearer

&client_assertion=Base64UrlEncoded-SAML2-Bearer-Assertion



probably the same works with JWT



Sergey





Thanks,

George



On 8/28/13 12:28 PM, Anthony Nadalin wrote:

I do think that this is the rare-edge use case, we would not want

require client-secret, we already have that mess today with OAuth and

trying not to continue the proliferation, we solve this today with our

STS and assertion swaps/transformations, it scales, performs and we

don't have the management debacle this specification creates



*From:*oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org> 
[mailto:oauth-boun...@ietf.org] *On

Behalf Of *George Fletcher

*Sent:* Wednesday, August 28, 2013 9:21 AM

*To:* Phil Hunt

*Cc:* oauth mailing list

*Subject:* Re: [OAUTH-WG] Dynamic Client Registration Conference Call:

Wed 28 Aug, 

Re: [OAUTH-WG] Fwd: [oauth-interop] scope and reach of testing activity

[Anthony Nadalin]

One thing to look at are the OpenID Connect interop tests and the 
portions/flows of OAuth that it covers, as that is going on now.

From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Prateek Mishra
Sent: Monday, October 7, 2013 2:39 PM
To: IETF oauth WG
Subject: [OAUTH-WG] Fwd: [oauth-interop] scope and reach of testing activity

Folks interested in OAuth interop/implementation testing may want to 
participate in this discussion.

Details at:
http://www.ietf.org/mail-archive/web/oauth/current/msg12128.html

 Original Message 
Subject:

[oauth-interop] scope and reach of testing activity

Date:

Fri, 04 Oct 2013 16:48:50 -0700

From:

Prateek Mishra 

Organization:

Oracle Corporation

To:

oauth-inte...@elists.isoc.org



Hello OAuth Interop list,



I would be interested in kicking off a discussion around the definition

of scope and reach of the proposed testing activity.



OAuth interop, of course, is the core activity. I assume this would take

the form of testing the exchanges described

in Sections 4-6  of RFC 6749 for each of the different client and grant

types. Both positive and negative tests would presumably be included.



But OAuth is also a security specification, and there are constraints

defined over OAuth server and client behavior with respect to

redirect_uri checking,

access code and token lifetimes and so on. In addition to the material

in Sections 4-6, there are additional constraints described in

Section 10 and, of course, RFC 6819. So thats another area that would

benefit from a set of tests, but I can see that describing these tests

might be more challenging.



I would be interested in other opinions on the scope and nature of tests

being developed by this group.



- prateek



___

Oauth-interop mailing list

oauth-inte...@elists.isoc.org

https://elists.isoc.org/mailman/listinfo/oauth-interop


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

Re: [OAUTH-WG] FYI per a request on the last conference call, this is a method for making client registration stateless.

[Anthony Nadalin]

Phil, I agree with your observations, seem like its screwed up

From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Phil 
Hunt
Sent: Monday, October 21, 2013 10:21 AM
To: John Bradley
Cc: oauth list
Subject: Re: [OAUTH-WG] FYI per a request on the last conference call, this is 
a method for making client registration stateless.

I am assuming that this draft fits with the dyn reg draft.  It makes the 
assumption that every single client is somehow potentially different in terms 
of registration.  This draft encodes the registration values in the JWT so that 
stateless registration can be achieved.

Dynamic registration takes a different view from client association, in that 
dynamic registration has no notion of fixed client software releases that are 
deployed many times. As such there is no fixed registration profile. Every 
client is potentially different. In contrast Client Association + Software 
statements, clients are identified as a particular software and are fixed.

Have I read this correctly?

>From a policy perspective, how would a service provider handle registration of 
>clients that are all potentially different? Why would individual clients need 
>to differ in registration (other than in the tokens negotiated with a 
>particular deployment SP)?

Phil

@independentid
www.independentid.com
phil.h...@oracle.com

On 2013-10-14, at 5:01 PM, John Bradley 
mailto:ve7...@ve7jtb.com>> wrote:


A new version of I-D, draft-bradley-stateless-oauth-client-00.txt
has been successfully submitted by John Bradley and posted to the
IETF repository.

Filename:  draft-bradley-stateless-oauth-client
Revision:  00
Title: Stateless Client Identifier for OAuth 2
Creation date:  2013-10-15
Group:  Individual Submission
Number of pages: 4
URL: 
http://www.ietf.org/internet-drafts/draft-bradley-stateless-oauth-client-00.txt
Status:  
http://datatracker.ietf.org/doc/draft-bradley-stateless-oauth-client
Htmlized:
http://tools.ietf.org/html/draft-bradley-stateless-oauth-client-00


Abstract:
  This draft provides a method for communicating information about an
  OAuth client through its client identifier allowing for fully
  stateless operation.





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

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

[OAUTH-WG] Proof of Possession

[Anthony Nadalin]

Hannes, we would like 10min on the agenda at the Vancouver IETF meeting to 
present/discuss POP
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth Agenda for IETF-88

[Anthony Nadalin]

The client registration is still open, so we need to continue our discussion 
that was started with the interim call

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Derek 
Atkins
Sent: Thursday, October 31, 2013 1:07 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] OAuth Agenda for IETF-88

The IETF is next week, and OAuth meets Monday Afternoon.  We have a 2-1/2 hour 
session, and I expect we'll use most of it for discussion.  For anyone who 
wants to make a status update on their draft please:

1) Get me slides before the meeting so I can post them online,
2) Try to keep yourself to a MAX of THREE (3) slides
3) Try to keep your comments to under 10 minutes (under 5 even better)

Face to face time is best used for discussion, not presentation.  :)

Here is the proposed agenda.  I'll post this on the website before the meeting 
on Monday.  Please let me know if you have any additions before then.


* Welcome & Agenda Bashing (10 minutes)
* Draft Statuses (20 minutes)
* Discussion (2 hours)
  - draft-bradley-stateless-oauth-client (30 min max)
  - Proof of Possession (30 min max)
  - Dynamic Client Registration (remainder, 60+min)
* draft-richer-oauth-dyn-reg-core
* draft-richer-oauth-dyn-reg-management
* ...


-derek

-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant

___
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 Agenda for IETF-88

[Anthony Nadalin]

Would like 10 min to discuss ActAs draft

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Derek 
Atkins
Sent: Thursday, October 31, 2013 1:07 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] OAuth Agenda for IETF-88

The IETF is next week, and OAuth meets Monday Afternoon.  We have a 2-1/2 hour 
session, and I expect we'll use most of it for discussion.  For anyone who 
wants to make a status update on their draft please:

1) Get me slides before the meeting so I can post them online,
2) Try to keep yourself to a MAX of THREE (3) slides
3) Try to keep your comments to under 10 minutes (under 5 even better)

Face to face time is best used for discussion, not presentation.  :)

Here is the proposed agenda.  I'll post this on the website before the meeting 
on Monday.  Please let me know if you have any additions before then.


* Welcome & Agenda Bashing (10 minutes)
* Draft Statuses (20 minutes)
* Discussion (2 hours)
  - draft-bradley-stateless-oauth-client (30 min max)
  - Proof of Possession (30 min max)
  - Dynamic Client Registration (remainder, 60+min)
* draft-richer-oauth-dyn-reg-core
* draft-richer-oauth-dyn-reg-management
* ...


-derek

-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant

___
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-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 
mailto: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
mailto: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 your case) includes the key but of course then
yo

Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00

[Anthony Nadalin]

We have mechanisms to do this it's not in our scope to start to encode the 
client_id with authentication information

From: Nat Sakimura [mailto:sakim...@gmail.com]
Sent: Monday, November 4, 2013 1:57 PM
To: Anthony Nadalin
Cc: Hannes Tschofenig; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00

See my reply to Justin.

BTW, is not the client authentication one of the pain point for the server that 
we want to solve statelessly?

2013/11/5 Anthony Nadalin mailto:tony...@microsoft.com>>
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> 
[mailto: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<mailto: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 
mailto: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
mailto: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 s

Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00

[Anthony Nadalin]

Identification is fine as long as it remains opaque and not specific to any 
format. Authentication remains out of scope

From: John Bradley [mailto:ve7...@ve7jtb.com]
Sent: Monday, November 4, 2013 2:05 PM
To: Anthony Nadalin
Cc: Nat Sakimura; Hannes Tschofenig; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00

The method the AS uses to identify the client is within the scope of the WG.  
We have several drafts that relate to that topic of extending that mechanism.

What we are discussing is how best to do that securely without requiring the AS 
to issue and maintain per client passwords.

John B.


On Nov 4, 2013, at 1:48 PM, Anthony Nadalin 
mailto:tony...@microsoft.com>> wrote:


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> 
[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<mailto: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 
mailto: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
mailto: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
dumpi

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] Dynamic Registration Plan: Your Feedback Needed!

[Anthony Nadalin]

I would agree with Phil, the server makes right in this case, specific 
statement may be sent but the processed statement is returned which may be 
different

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Thursday, February 6, 2014 10:39 AM
To: Phil Hunt
Cc: oauth@ietf.org list
Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!

I think it would be echoing back the software statement  that was processed as 
part of the request for consistency.   Replying with a different software 
statement is going to be too confusing.   
The entirety of the reply represents the configured state for the client.

John B.

On Feb 6, 2014, at 3:33 PM, Phil Hunt  wrote:

> My thought was the original statement shouldn't be returned because the 
> server would return the "processed" information.  IOW reflecting what it took 
> from the certificate vs. from the registration request.
> 
> If you just echo back the certificate you aren't necessarily reflecting the 
> final state of the registration.
> 
> I'm pretty open on this. Just want to make clear on what state we are 
> returning (if any).
> 
> Phil
> 
> @independentid
> www.independentid.com
> phil.h...@oracle.com
> 
> On 2014-02-05, at 6:11 PM, Mike Jones  wrote:
> 
>> Oh, I should add that I disagree that it's not necessary to return the 
>> software statement.  It's a key part of the client registration information, 
>> and so should be returned like the other client registration information 
>> actually used.
>> 
>>  -- Mike
>> 
>> -Original Message-
>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
>> Sent: Wednesday, February 05, 2014 6:08 PM
>> To: Phil Hunt; Eve Maler
>> Cc: oauth@ietf.org list
>> Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!
>> 
>> Thanks for your comments, Phil.  I'm working on addressing them at present.
>> 
>> One comment confuses me.  You wrote "Section 4.1 - It would be good to have 
>> an example with a software statement and no initial access token (or both)." 
>>  Yet the last example in Section 4.1 already is such as an example (taken 
>> from draft-hunt-oauth-client-association, actually).  Was there something 
>> else that you were thinking of?
>> 
>> Also, the "Deployment Organization" definition *does* describe when it and 
>> the deployment organization are different.  Where I think that the text 
>> describing the choices for the two cases belongs is a subsection of the Use 
>> Cases appendix.  Do you want to write text about the two cases, Phi?
>> 
>>  -- Mike
>> 
>> -Original Message-
>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt
>> Sent: Monday, February 03, 2014 12:18 PM
>> To: Eve Maler
>> Cc: oauth@ietf.org list
>> Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!
>> 
>> I am generally in agreement on the new drafts.  Thanks Mike!
>> 
>> Here are some comments:
>> 
>> In the software statement section 3:
>>> If the authorization server determines that the claims in a software  
>>> statement uniquely identify a piece of software, the same Client ID  
>>> value MAY be returned for all dynamic registrations using that  
>>> software statement.
>>> 
>>>  In some cases, authorization servers MAY choose to accept a 
>>> software  statement value directly as a Client ID in an 
>>> authorization request,  without a prior dynamic client registration having 
>>> been performed.
>>>  The circumstances under which an authorization server would do so,  
>>> and the specific software statement characteristics required in this  
>>> case, are beyond the scope of this specification.
>>> 
>> 
>> We should call out that the server MAY also issue per instance client_id's 
>> (the opposite of the first quoted paragraph above) if it chooses to use 
>> client_id as an instance identifier (the software_id identifies what clients 
>> are based on the same software).  I think this will be the typical use case. 
>> Not sure whether the first paragraph should be re-written, or a new one 
>> added.
>> 
>> Section 4.1
>> It would be good to have an example with a software statement and no initial 
>> access token (or both).
>> 
>> Section 5.1
>> Should we also say that is not necessary to return the software statement.  
>> Note: the server should return the meta data that was obtained from the 
>> statement.
>> 
>> Dyn-Reg-Metadata
>> The metadata document looks fine.  I would prefer it being included in dyn 
>> reg, but can live with it as is.
>> 
>> Dyn-Reg-Management
>> I'd like to discuss this more in London.  I think a SCIM based management 
>> API may be simpler to write up and can leverage the features of SCIM without 
>> having to redefine them in a new API.  Still, SCIM is a way off from 
>> approval -- so I understand the need to move forward now. Is experimental 
>> the right way to go?  I am not sure

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] OAuth + Open ID Connect Meeting: Sunday, March 2

[Anthony Nadalin]

May things should change back as announced? Things in life chnage

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Tuesday, February 25, 2014 11:58 AM
To: Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] OAuth + Open ID Connect Meeting: Sunday, March 2

Yes.

Things change that's life.



Sent from my iPhone

On Feb 25, 2014, at 8:16 PM, Brian Campbell 
mailto: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 
mailto: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

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  wrote:
> Yes.
>
> Things change that's life.
>
>
>
> Sent from my iPhone
>
> On Feb 25, 2014, at 8:16 PM, Brian Campbell 
> 
> 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 
>  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]

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  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  wrote:
>>> Yes.
>>>
>>> Things change that's life.
>>>
>>>
>>>
>>> Sent from my iPhone
>>>
>>> On Feb 25, 2014, at 8:16 PM, Brian Campbell 
>>> 
>>> 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 
>>>  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] Discussion about Dynamic Client Registration Management Work

[Anthony Nadalin]

MFW

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Morteza Ansari 
(moransar)
Sent: Tuesday, March 4, 2014 10:34 AM
To: Hannes Tschofenig; oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion about Dynamic Client Registration Management 
Work

WFM too.

On 3/4/14 6:04 PM, "Hannes Tschofenig"  wrote:

>Hi all,
>
>at today's OAuth meeting I suggested to get together during the week to 
>continue our conversation about draft-ietf-oauth-dyn-reg-management-00,
>which dominated our conversation at the meeting today.
>
>I would suggest to get together on **Thursday, at 11:30** (for lunch) 
>at the IETF registration desk.
>
>Objections?*
>
>Ciao
>Hannes
>
>PS: I know that your schedule during the IETF meeting is quite full ...
>

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

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 group<http://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 versions<http://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.org<mailto:oauth@ietf.org> list
Subject: [OAUTH-WG] Working Group Versions of Refactored OAuth Dynamic Client 
Registration Specs

There are now OAuth working group<http://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 versions<http://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 Last Call on Dynamic Client Registration Documents

[Anthony Nadalin]

If these are going to be combined then a draft should be produced and then a 
decision should be made once everyone has a chance to review

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
Sent: Friday, April 4, 2014 5:49 PM
To: Hannes Tschofenig; oauth@ietf.org
Subject: Re: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration 
Documents

I would combine these two documents, with no normative changes.  This would be 
a convenience for implementers.  And the metadata values that are currently 
optional would remain optional.

I would also add an optional "jwks" metadata member, paralleling this addition 
in OpenID Connect Registration.  This allows the JWK Set to be passed by value, 
rather than by reference.  This was discussed in London and people seemed to 
agree with this change.

The reference to RFC 4627 should be changed to RFC 7159, which has obsoleted 
4627.

Other than that, I believe they're ready to proceed on the next steps towards 
becoming an RFC.

-- Mike

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Friday, April 04, 2014 2:14 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration 
Documents

Hi all,

This is a Last Call for comments on the dynamic client registration
documents:

* OAuth 2.0 Dynamic Client Registration Core Protocol
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-16

* OAuth 2.0 Dynamic Client Registration Metadata
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-metadata-00

Since we have to do the last call for these two documents together we are 
setting the call for **3 weeks**.

Please have your comments in no later than April 25th.

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] 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.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 
mailto:phil.h...@oracle.com>> wrote:

What was wrong with HOK?

Aside: Why was "the" so important in HOTK?

Phil

@independentid
www.independentid.com
phil.h...@oracle.com

On Apr 3, 2014, at 9:37 AM, Anil Saldhana 
mailto: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.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.org.

The IETF Secretariat

___
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 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 
mailto: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 
mailto: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: 

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as
a Proposed Standard
Starting point: 

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: 

-

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.org
https://www.ietf.org/mailman/listinfo/oauth



--
[Ping Identity logo]

Brian Campbell
Portfolio Architect
@

bcampb...@pingidentity.com

[phone]

+1 720.317.2061

Connect with us…

[twitter logo][youtube 
logo][LinkedIn 
logo][Facebook 
logo][Google+ 
logo][slideshare 
logo][flipboard 
logo][rss feed icon]


[Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19–23 
July, 2014 | Monterey, CA]


_

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 
mailto: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 
mailto: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: 

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as
a Proposed Standard
Starting point: 

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: 

-

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.org
https://www.ietf.org/mailman/listinfo/oauth



--
[Ping Identity logo]

Brian Campbell
Portfolio Architect
@

bcampb...@pingidentity.com

[phone]

+1 720.317.2061

Connect with us…

[twitter logo][youtube 
logo][LinkedIn 
logo][Facebook 
logo][Google+ 
logo][slideshare 
logo][flipboard 
logo][rss feed icon]


[Register for Cloud Identity Summit 201

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 
mailto: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.org<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<mailto: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 
mailto: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 
mailto: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: 

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as
a Proposed Standard
Starting point: 

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: 

-

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 

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 
mailto: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 
mailto: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: 

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as
a Proposed Standard
Starting point: 

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: 

-

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.org
https://www.ietf.org/mailman/listinfo/oauth



--
[Ping Identity logo]

Brian Campbell
Portfolio Architect
@

bcampb...@pingidentity.com

[phone]

+1 720.317.2061

Connect with us…

[twitter logo][youtube 
logo][LinkedIn 
logo][Facebook 
logo][Google+ 
logo][slideshare 
logo][flipboard 
logo][rss feed icon]


[Register for Cloud Identity Summit 2014 | Mod

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 
mailto: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 
mailto: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.org] On 
Behalf Of Phil Hunt
Sent: Thursday, June 05, 2014 8:54 AM
To: Hannes Tschofenig
Cc: 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 
> mailto: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.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] 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 
mailto: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.org<mailto: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 
mailto: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 
mailto: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.org<mailto:oauth-boun...@ietf.org>] On 
Behalf Of Phil Hunt
Sent: Thursday, June 05, 2014 8:54 AM
To: Hannes Tschofenig
Cc: oauth@ietf.org<mailto: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 
> mailto: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.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth


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

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

Re: [OAUTH-WG] 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-Trust (this MS 
FAQ 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 
mailto: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 mailto:vladi...@connect2id.com>>
Connect2id Ltd.

___
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-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 
mailto: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.org<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<mailto: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-Trust<http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html> (this MS 
FAQ<http://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 
mailto: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 mailto:vladi...@connect2id.com>>
Connect2id Ltd.

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


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

Re: [OAUTH-WG] 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.3<http://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 
mailto: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.com<http://www.independentid.com/>
phil.h...@oracle.com<mailto:phil.h...@oracle.com>



On Jul 3, 2014, at 12:20 PM, Mike Jones 
mailto: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.org<mailto: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.org<mailto: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 
mailto: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 d

Re: [OAUTH-WG] Shepherd Writeup for Dynamic Client Registration Draft

[Anthony Nadalin]

Is your implementation from the OpenID Connect specification of from the IETF 
specification

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Edmund Jay
Sent: Tuesday, July 15, 2014 11:01 AM
To: Hannes Tschofenig; oauth@ietf.org
Subject: Re: [OAUTH-WG] Shepherd Writeup for Dynamic Client Registration Draft

I've implemented registration as part of OpenID Connect.

server - https://connect.openid4.us/abop
client - https://connect.openid4.us/abrp



From: Hannes Tschofenig 
mailto:hannes.tschofe...@gmx.net>>
To: "oauth@ietf.org" 
mailto:oauth@ietf.org>>
Sent: Tuesday, July 8, 2014 5:46 AM
Subject: [OAUTH-WG] Shepherd Writeup for Dynamic Client Registration Draft

Hi all,

I am working on the shepherd writeup for the dynamic client registration
draft.

You can find the latest draft here:
https://github.com/hannestschofenig/tschofenig-ids/blob/master/shepherd-writeups/Writeup_OAuth_DynamicClientRegistration.txt

As you can see it is still incomplete.

I would need information about the implementation status.

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] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt

[Anthony Nadalin]

if we take Ian’s non technical  advice then most of the work in Oauth should be 
put down.

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura
Sent: Thursday, July 24, 2014 5:29 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

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 
mailto: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.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 channel_id so we can do PoP 
for id tokens to make them and other cookies secure in the front channel.   I 
think that is a better use of time.

I may be in the minority opinion on that,  it won't be the first time.


John B.
Sent from my iPhone

On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt 
mailto:tors...@lodderstedt.net>> wrote:
You are right from a theoretical perspective. Practically this was caused by 
editorial decisions during the creation of the RFC. As far as I remember, there 
was a definition of the (one) token endpoint response in early versions. No one 
every considered to NOT respond with an access token from the token endpoint. 
So one might call it an implicit assumption.

I'm worried that people get totally confused if an exception is introduced now 
given the broad adoption of OAuth based on this assumption.

regards,
Torsten.

Am 23.07.2014 um 15:41 schrieb Thomas Broyer 
mailto:t.bro...@gmail.com>>:

Is it said anywhere that ALL grant types MUST use Section 5.1 responses? Each 
grant type references Section 5.1, and "access token request" is only defined 
in the context of the defined grant types. Section 2.2 doesn't talk about the 
request or response format.
Le 23 juil. 2014 21:32, "Nat Sakimura" 
mailto:sakim...@gmail.com>> a écrit :
Is it? Apart from the implicit grant that does not use token endpoint, all 
other grant references section 5.1 for the response, i.e., all shares the same 
response.

2014-07-23 15:18 GMT-04:00 Thomas Broyer 
mailto:t.bro...@gmail.com>>:

I hadn't realized the JSON response that requires the access_token field is 
defined per grant_type, so I'd be OK to "extend the semantics" as in the 
current draft.
That was actually my main concern: that the token endpoint mandates 
access_token; but its actually not the case.
Le 23 juil. 2014 20:46, "Nat Sakimura" 
mailto:sakim...@gmail.com>> a écrit :

I agree with John that overloading response_type @ authz endpoint is a bad 
idea. It completely changes the semantics of this parameter. NOTE: what I was 
proposing was not this parameter, but a new parameter response_type @ token 
endpoint.

I also think overloading grant_type is a bad idea since it changes its 
semantics. I quote the definition here again:

grant
credential representing the resource owner's authorization

grant_type
type of grant sent to the token endpoint to obtain the access token

It is not about controlling what is to be returned from the token endpoint, but 
the hint to the token endpoint describing the type of credential the endpoint 
has received. It seems the "control of what is being returned from token 
endpoint"  is just a side effect.

I am somewhat ambivalent[1] in changing the semantics of token endpoint, but in 
as much as "text is the king" for a spec., we probably should not change the 
semantics of it as Torsten points out. If it is ok to change this semantics, I 
believe defining a new parameter to this endpoint to control the response would 
be the best way to go. This is what I have described previously.

Defining a new endpoint to send code to get ID Token and forbidding the use of 
it against token endpoint would not change the semantics of any existing 
parameter or endpoint, which is good. However, I doubt if it is not worth 
doing. What's the point of avoiding access token scoped to UserInfo endpoint 
after all? Defining a new endpoint for just avoiding the access token for 
userinfo endpoint seems way too much the heavy wait way and it breaks 
interoperabiliy: it defeats t

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt

[Anthony Nadalin]

I’m sure it was spun in a way that could be true since there was no technical 
value to Ian’s statement and I’m sure that folks had not read or understand the 
usage.

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, July 24, 2014 6:53 AM
To: Nat Sakimura
Cc: oauth@ietf.org list
Subject: Re: [OAUTH-WG] New Version Notification for 
draft-hunt-oauth-v2-user-a4c-05.txt

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 
mailto: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 
mailto: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.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 channel_id so we can do PoP 
for id tokens to make them and other cookies secure in the front channel.   I 
think that is a better use of time.

I may be in the minority opinion on that,  it won't be the first time.


John B.
Sent from my iPhone

On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt 
mailto:tors...@lodderstedt.net>> wrote:
You are right from a theoretical perspective. Practically this was caused by 
editorial decisions during the creation of the RFC. As far as I remember, there 
was a definition of the (one) token endpoint response in early versions. No one 
every considered to NOT respond with an access token from the token endpoint. 
So one might call it an implicit assumption.

I'm worried that people get totally confused if an exception is introduced now 
given the broad adoption of OAuth based on this assumption.

regards,
Torsten.

Am 23.07.2014 um 15:41 schrieb Thomas Broyer 
mailto:t.bro...@gmail.com>>:

Is it said anywhere that ALL grant types MUST use Section 5.1 responses? Each 
grant type references Section 5.1, and "access token request" is only defined 
in the context of the defined grant types. Section 2.2 doesn't talk about the 
request or response format.
Le 23 juil. 2014 21:32, "Nat Sakimura" 
mailto:sakim...@gmail.com>> a écrit :
Is it? Apart from the implicit grant that does not use token endpoint, all 
other grant references section 5.1 for the response, i.e., all shares the same 
response.

2014-07-23 15:18 GMT-04:00 Thomas Broyer 
mailto:t.bro...@gmail.com>>:

I hadn't realized the JSON response that requires the access_token field is 
defined per grant_type, so I'd be OK to "extend the semantics" as in the 
current draft.
That was actually my main concern: that the token endpoint mandates 
access_token; but its actually not the case.
Le 23 juil. 2014 20:46, "Nat Sakimura" 
mailto:sakim...@gmail.com>> a écrit :

I agree with John that overloading response_type @ authz endpoint is a bad 
idea. It completely changes the semantics of this parameter. NOTE: what I was 
proposing was not this parameter, but a new parameter response_type @ token 
endpoint.

I also think overloading grant_type is a bad idea since it changes its 
semantics. I quote the definition here again:

grant
credential representing the resource owner's authorization

grant_type
type of grant sent to the token endpoint to obtain the access token

It is not about controlling what is to be returned from the token endpoint, but 
the hint to the token endpoint describing the type of credential the endpoint 
has received. It seems the "control of what is being returned from token 
endpoint"  is just a side effect.

I am somewhat ambivalent[1] in changing the semantics of token endpoint, but in 
as much as "text is the king" for a spec., we probably should not change the 
semantics of it as Torsten points out. If it is ok to change this semantics, I 
believe defining a new parameter to this endpoint to control the response would 
be the best way to go. This is what I have described previously.

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 
mailto: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 
mailto: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 
mailto: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 
mailto: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.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 channel_id so we can do PoP 
for id tokens to make them and other cookies 

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 
mailto: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.org<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<mailto: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 
mailto: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 
mailto: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 
mailto: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 
mailto: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

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: 
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 
mailto: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" 
mailto: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.com]
Sent: Tuesday, July 29, 2014 5:43 PM
To: Mike Jones
Cc: mailto: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" 
mailto: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.org] On 
Behalf Of George Fletcher
Sent: Tuesday, July 29, 2014 3:25 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

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 
mailto:t.bro...@gmail.com>> wrote:
Yes. This spec is of special interest to the platform we're building for 
http://www.oasis-eu.org/

On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig 
mailto:

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 Bradley
Sent: ‎7/‎30/‎2014 7:20 AM
To: Sergey Beryozkin
Cc: 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  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  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  
> wrote:

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] Working Group Last Call on "Symmetric Proof of Possession for the OAuth Authorization Code Grant"

[Anthony Nadalin]

Not all of us look at individual drafts, and thus I have not previously read 
this, but I did this morning and find that there are issues with the way the 
"code challenge" is specified as this requires pre negation of what/how that 
value was achieved and a large scale deployment that is almost impossible, if a 
JWK were used as the default this could eliminate some of the guess work and 
pre-negotiation work. 

I don't think it's ready for WGLC as there has been no discussion yet.

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Wednesday, August 27, 2014 8:45 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Working Group Last Call on "Symmetric Proof of 
Possession for the OAuth Authorization Code Grant"

Based on the reaction from a few I thought I should add a few words about this 
working group last call.

There is no requirement to wait a specific timeframe after a document became a 
WG item to issue a working group last call.

In this specific case, the document was around for a while and I didn't see a 
reason for not-finishing it as soon as possible.

Additionally, since the document deals with a security vulnerability that is 
being exploited today I thought it might make sense to get the attention from 
the group to review it.

Finally, it is also a fairly "simple" document (if there is something as simple 
in this working group).

Ciao
Hannes

On 08/26/2014 09:32 PM, Hannes Tschofenig wrote:
> Hi all,
> 
> This is a Last Call for comments on the "Symmetric Proof of Possession 
> for the OAuth Authorization Code Grant" specification.
> 
> The document can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-oauth-spop/
> 
> Please have your comments in no later than September 9th.
> 
> 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  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] 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

[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] 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 
mailto: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 t

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.org<mailto: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 
mailto:tony...@microsoft.com>> wrote:



Comments

Intro
"about the authentication conext", not sure what this is since there is no 
au

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: 
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 
mailto: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 Connect. Note that this is in a

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 consi

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 sy

[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] 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 Campbell
Sent: ‎3/‎25/‎2015 2:19 PM
To: Mike Jones
Cc: oauth
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 
mailto: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.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

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 
>>> >> -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 *
>>>
>>> *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 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 
Cc: oauth 
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 link 
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 
archive). 
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 
that 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 
mailto: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

-Original Message-
From: OAuth [mailto:oauth-boun...@i

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 
Cc: Mike Jones ; oauth 
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case

A natural usage of act-as or 
impersonation<http://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 
mailto: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.org<mailto:oauth-boun...@ietf.org>] On 
Behalf Of Brian Campbell
Sent: Monday, July 6, 2015 11:29 AM
To: Mike Jones mailto:michael.jo...@microsoft.com>>
Cc: oauth mailto: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 link<https://msdn.microsoft.com/en-us/library/ee748487.aspx> 
John gave is much 

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 
Cc:  
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 
mailto:michael.jo...@microsoft.com>> wrote:

As just updated, 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: mailto: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 
mailto: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 like it always would, with 
scopes [A, B, C] in order to call service A, which requires all three sc

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 ; Mike Jones 
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] confirmation model in proof-of-possession-02

[Anthony Nadalin]

 to 
>> flatten things so that the "cnf" elements would become individual 
>> claims, along the lines of "cnf_jwk", "cnf_jwe", "cnf_kid", etc.  
>> This was discussed in the thread " [OAUTH-WG] JWT PoP Key Semantics WGLC 
>> followup 3 (was Re:
>> confirmation model in proof-of-possession-02)" - for instance, John 
>> Bradley's message 
>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.i
>> etf.org%2fmail-archive%2fweb%2foauth%2fcurrent%2fmsg14859.html&data=0
>> 1%7c01%7ctonynad%40microsoft.com%7cc8935ea677b848a37dd308d2a2983ce7%7
>> c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=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%2c&data=01%7c01%7ctonynad%40microsoft.com%7cc8935ea677b848a37dd308d2a2983ce7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=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.html&data=0
>> 1%7c01%7ctonynad%40microsoft.com%7cc8935ea677b848a37dd308d2a2983ce7%7
>> c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=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%2c&dat
>> a=01%7c01%7ctonynad%40microsoft.com%7cc8935ea677b848a37dd308d2a2983ce7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=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 
>> 
>> 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
>>

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 
 mailto:michael.jo...@microsoft.com>> 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
 
 
 
 Proof-of-Possession Key Semantics for JWTs draft -06 addresses the 
 remaining document shepherd comment – adding use case diagrams to 
 the introduction.
 
 
 
 The updated specification 

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 
Cc: John Bradley ;  
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  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 
> 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 
>>>>> <

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 
Cc: Justin Richer ;  
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  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 
> 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 
>>>>> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-pop-key-distribution-02%23section-4.2&data=01%7c01%7ctonynad%40microsoft.com%7c9456670075d04a51f85508d2e59ba294%7c

Re: [OAUTH-WG] IETF 95 - Buenos Aires

[Anthony Nadalin]

I’m afraid that I would have to agree with Brian (hopefully this is not a trend)

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Friday, January 15, 2016 9:16 AM
To: Hannes Tschofenig 
Cc: oauth@ietf.org; Rolando Martínez 
Subject: Re: [OAUTH-WG] IETF 95 - Buenos Aires

Speaking for myself but I suspect others might be in the same boat - I'd love 
to see some additional time beyond the official meeting made available to try 
and make more progress on the open work in OAuth. But the week before IETF in a 
different country (even if it's only a 19h bus ride) just isn't logistically 
feasible for me.

On Fri, Jan 15, 2016 at 7:11 AM, Hannes Tschofenig 
mailto:hannes.tschofe...@gmx.net>> wrote:
Would it make sense to add an OAuth day to the OpenID Summit to prepare
the IETF meeting, to play around with code, etc?

On 01/15/2016 01:58 PM, John Bradley wrote:
> Yes I am going.
>
> The University of Chile and RedHat are sponsoring a one day OpenID Summit on 
> Mar 31.
>
> I will send the registration info to the list once we have it up.
>
> Anyone interested should email myself or Rolando who is cc’d on this.
>
> John B.
>
>> On Jan 15, 2016, at 6:08 AM, Hannes Tschofenig 
>> mailto:hannes.tschofe...@gmx.net>> wrote:
>>
>> Hi all,
>>
>> I have just requested a 2 hour meeting slot for the next IETF meeting in
>> Buenos Aires.
>>
>> It would be good to know whether you are planning to attend the upcoming
>> IETF meeting. Please drop me a private mail to tell me your plans.
>>
>> 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