Re: [OAUTH-WG] Call for adoption for draft-wahlstroem-ace-cbor-web-token-00

[Mike Jones]

+1 for adoption

From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Kepeng Li
Sent: Wednesday, April 6, 2016 10:35 PM
To: a...@ietf.org
Cc: Kathleen Moriarty ; Hannes Tschofenig 
; c...@ietf.org; oauth@ietf.org; Stephen Farrell 

Subject: [Ace] Call for adoption for draft-wahlstroem-ace-cbor-web-token-00

To: ACE WG
Cc: OAuth and COSE WG

Hello all,



This note begins a Call For Adoption for draft-wahlstroem-ace-cbor-web-token-00 
[1]
to be adopted as an ACE working group item, and added in the charter.
The call ends on April 22, 2016.


Keep in mind that adoption of a document does not mean the document

as-is is ready for publication. It is merely acceptance of the

document as a starting point for what will be the final product

of the ACE working group. The working group is free to make changes to

the document according to the normal consensus process.



Please reply on this thread with expressions of support or opposition,

preferably with comments, regarding accepting this as a work item.

Note that this email was also copied to OAuth and COSE WG, in order to
get input from wider audience.



Thanks,



Kind Regards

Kepeng (ACE co-chair)

[1] https://datatracker.ietf.org/doc/draft-wahlstroem-ace-cbor-web-token/

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

[OAUTH-WG] Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) is now RFC 7800

[Mike Jones]

The Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) specification 
is now RFC 7800 - an IETF standard. The 
abstract describes the specification as:

This specification describes how to declare in a JSON Web Token (JWT) that the 
presenter of the JWT possesses a particular proof-of-possession key and how the 
recipient can cryptographically confirm proof of possession of the key by the 
presenter. Being able to prove possession of a key is also sometimes described 
as the presenter being a holder-of-key.

Thanks to John Bradley, Hannes 
Tschofenig, and the OAuth working group for their 
work on this specification.

  -- Mike

P.S.  This notice was also posted at http://self-issued.info/?p=1561 and as 
@selfissued.

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

[OAUTH-WG] RFC 7800 on Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)

[rfc-editor]

A new Request for Comments is now available in online RFC libraries.


RFC 7800

Title:  Proof-of-Possession Key Semantics for JSON 
Web Tokens (JWTs) 
Author: M. Jones, J. Bradley, H. Tschofenig
Status: Standards Track
Stream: IETF
Date:   April 2016
Mailbox:m...@microsoft.com, 
ve7...@ve7jtb.com, 
hannes.tschofe...@gmx.net
Pages:  15
Characters: 33625
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-oauth-proof-of-possession-11.txt

URL:https://www.rfc-editor.org/info/rfc7800

DOI:http://dx.doi.org/10.17487/RFC7800

This specification describes how to declare in a JSON Web Token (JWT)
that the presenter of the JWT possesses a particular proof-of-
possession key and how the recipient can cryptographically confirm
proof of possession of the key by the presenter.  Being able to prove
possession of a key is also sometimes described as the presenter
being a holder-of-key.

This document is a product of the Web Authorization Protocol Working Group of 
the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


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

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

[Nov Matake]

I'm interested in too.

nov

> On Apr 7, 2016, at 07:14, Mike Jones  wrote:
> 
> For the record, I’m interested.
>  
> From: scim [mailto:scim-boun...@ietf.org] On Behalf Of Hardt, Dick
> Sent: Tuesday, April 5, 2016 7:26 PM
> To: Phil Hunt (IDM) 
> Cc: s...@ietf.org; oauth@ietf.org
> Subject: Re: [scim] Simple Federation Deployment
>  
> I’m talking about removing manual steps in what happens today where 
> configuring a SaaS app at an IdP (such as Google, Azure, Ping, Octa) requires 
> is a bunch of cutting and pasting of access tokens / keys / certs and doing a 
> bunch of  config that is error prone and unique for each relationship.
>  
> Don’t want to solve on the thread … looking to see if there is interest!
>  
> On 4/5/16, 7:11 PM, someone claiming to be "scim on behalf of Phil Hunt 
> (IDM)"  wrote:
>  
> Is the idp the center of all things for these users?
>  
> Usually you have a provisioning system that coordinates state and uses things 
> like scim connectors to do this. 
>  
> Another approach from today would be to pass a scim event to the remote 
> provider which then decides what needs to be done to facilitate the thingd 
> you describe. 
>  
> Iow. Either the idp (sender) or the sp (receiver) have a provisioning system 
> to do this. 
>  
> The solution and the simplicity depends on where the control needs to be. 
> 
> Phil
> 
> On Apr 5, 2016, at 18:59, Hardt, Dick  wrote:
> 
> Use case: An admin for an organization would like to enable her users to 
> access a SaaS application at her IdP. 
>  
> User experience: 
> Admin authenticates to IdP in browser
> Admin selects SaaS app to federate with from list at IdP
> IdP optionally presents config options
> IdP redirects Admin to SaaS app
> Admin authenticates to SaaS app
> SaaS app optionally gathers config options
> SaaS app redirects admin to IdP
> IdP confirms successful federation => OIDC / SAML and SCIM are now configured 
> and working between IdP and SaaS App
> Who else is interested in solving this?
>  
> Is there interest in working on this in either SCIM or OAUTH Wgs?
>  
> Any one in BA interested in meeting on this topic this week?
>  
> ― Dick
> ___
> scim mailing list
> s...@ietf.org
> https://www.ietf.org/mailman/listinfo/scim
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

For the record, I’m interested.

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

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

Don’t want to solve on the thread … looking to see if there is interest!

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

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

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

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

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

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

Phil

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

User experience:

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

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

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

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

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

[Ian Glazer]

I'd be interested too

On Tue, Apr 5, 2016 at 5:59 PM, Hardt, Dick  wrote:

> Use case: An admin for an organization would like to enable her users to
> access a SaaS application at her IdP.
>
> User experience:
>
>1. Admin authenticates to IdP in browser
>2. Admin selects SaaS app to federate with from list at IdP
>3. IdP optionally presents config options
>4. IdP redirects Admin to SaaS app
>5. Admin authenticates to SaaS app
>6. SaaS app optionally gathers config options
>7. SaaS app redirects admin to IdP
>8. IdP confirms successful federation => OIDC / SAML and SCIM are now
>configured and working between IdP and SaaS App
>
> Who else is interested in solving this?
>
> Is there interest in working on this in either SCIM or OAUTH Wgs?
>
> Any one in BA interested in meeting on this topic this week?
>
> — Dick
>
> ___
> scim mailing list
> s...@ietf.org
> https://www.ietf.org/mailman/listinfo/scim
>
>


-- 
Ian Glazer
Senior Director, Identity
+1 202 255 3166
@iglazer 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[John Bradley]

I support adoption by the WG.


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

[Brian Campbell]

Please read the draft.

On Wed, Apr 6, 2016 at 5:16 PM, Anthony Nadalin 
wrote:

> I don’t see anything in the document that allows multiple resource servers
> where the token can be used. Token Exchange allows delegation and
> impersonation, so I have no idea of the semantics when I use both of these
> together
>
>
>
> *From:* Brian Campbell [mailto:bcampb...@pingidentity.com]
> *Sent:* Wednesday, April 6, 2016 1:13 PM
> *To:* Anthony Nadalin 
> *Cc:* Phil Hunt (IDM) ; oauth@ietf.org
>
> *Subject:* Re: [OAUTH-WG] Call for Adoption: Resource Indicators for
> OAuth 2.0
>
>
>
> Multiple resources are there now.
>
> I have no idea what "interaction with Token Exchange" means. Can you
> please explain?
>
>
>
> On Wed, Apr 6, 2016 at 5:04 PM, Anthony Nadalin 
> wrote:
>
> I would like to see the multiple resources servers, interaction with Token
> Exchange resolved before this is adopted to see if this will actually solve
> the problems
>
>
>
> *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Brian
> Campbell
> *Sent:* Wednesday, April 6, 2016 12:52 PM
> *To:* Phil Hunt (IDM) 
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Call for Adoption: Resource Indicators for
> OAuth 2.0
>
>
>
> I support the adoption of this draft by the working group.
>
> I don't think an immediate WGLC was expected here.
>
>
>
> On Wed, Apr 6, 2016 at 4:06 PM, Phil Hunt (IDM) 
> wrote:
>
> With the process of immediate wglc I think we should review all documents
> more thoroughly before adoption.
>
> As I said I support the work.
>
> Phil
>
>
> > On Apr 6, 2016, at 16:02, Hannes Tschofenig 
> wrote:
> >
> > Phil,
> >
> > we have discussed this concept already for years. In fact, it dates back
> > to the days of the OAuth base specification and the security
> > consideration section even talks about it.
> >
> > We have had the content of this in the PoP key distribution draft and we
> > are now moving it into a separate document.
> >
> > I am not sure how much longer you want to discuss it.
> >
> > Ciao
> > Hannes
> >
> >
> >> On 04/06/2016 08:07 PM, Phil Hunt (IDM) wrote:
> >> I would like to have more discussion before wg adoption.
> >>
> >> I support the work and am willing to help.
> >>
> >> Phil
> >>
> >>> On Apr 6, 2016, at 14:25, Hannes Tschofenig 
> wrote:
> >>>
> >>> Hi all,
> >>>
> >>> this is the call for adoption of 'Resource Indicators for OAuth 2.0',
> see
> >>>
> http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/
> 
> >>>
> >>> Please let us know by April 20th whether you accept / object to the
> >>> adoption of this document as a starting point for work in the OAuth
> >>> working group.
> >>>
> >>> Note: If you already stated your opinion at the IETF meeting in Buenos
> >>> Aires then you don't need to re-state your opinion, if you want.
> >>>
> >>> The feedback at the BA IETF meeting was the following: ~10 persons
> >>> for accepting the document and 0 persons against.
> >>>
> >>> Ciao
> >>> Hannes & Derek
> >>>
> >>> ___
> >>> OAuth mailing list
> >>> OAuth@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/oauth
> 
> >
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
>
>
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Anthony Nadalin]

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

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

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

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

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

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

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

As I said I support the work.

Phil

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

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


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

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

[Brian Campbell]

Multiple resources are there now.

I have no idea what "interaction with Token Exchange" means. Can you please
explain?

On Wed, Apr 6, 2016 at 5:04 PM, Anthony Nadalin 
wrote:

> I would like to see the multiple resources servers, interaction with Token
> Exchange resolved before this is adopted to see if this will actually solve
> the problems
>
>
>
> *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Brian
> Campbell
> *Sent:* Wednesday, April 6, 2016 12:52 PM
> *To:* Phil Hunt (IDM) 
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Call for Adoption: Resource Indicators for
> OAuth 2.0
>
>
>
> I support the adoption of this draft by the working group.
>
> I don't think an immediate WGLC was expected here.
>
>
>
> On Wed, Apr 6, 2016 at 4:06 PM, Phil Hunt (IDM) 
> wrote:
>
> With the process of immediate wglc I think we should review all documents
> more thoroughly before adoption.
>
> As I said I support the work.
>
> Phil
>
>
> > On Apr 6, 2016, at 16:02, Hannes Tschofenig 
> wrote:
> >
> > Phil,
> >
> > we have discussed this concept already for years. In fact, it dates back
> > to the days of the OAuth base specification and the security
> > consideration section even talks about it.
> >
> > We have had the content of this in the PoP key distribution draft and we
> > are now moving it into a separate document.
> >
> > I am not sure how much longer you want to discuss it.
> >
> > Ciao
> > Hannes
> >
> >
> >> On 04/06/2016 08:07 PM, Phil Hunt (IDM) wrote:
> >> I would like to have more discussion before wg adoption.
> >>
> >> I support the work and am willing to help.
> >>
> >> Phil
> >>
> >>> On Apr 6, 2016, at 14:25, Hannes Tschofenig 
> wrote:
> >>>
> >>> Hi all,
> >>>
> >>> this is the call for adoption of 'Resource Indicators for OAuth 2.0',
> see
> >>>
> http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/
> 
> >>>
> >>> Please let us know by April 20th whether you accept / object to the
> >>> adoption of this document as a starting point for work in the OAuth
> >>> working group.
> >>>
> >>> Note: If you already stated your opinion at the IETF meeting in Buenos
> >>> Aires then you don't need to re-state your opinion, if you want.
> >>>
> >>> The feedback at the BA IETF meeting was the following: ~10 persons
> >>> for accepting the document and 0 persons against.
> >>>
> >>> Ciao
> >>> Hannes & Derek
> >>>
> >>> ___
> >>> OAuth mailing list
> >>> OAuth@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/oauth
> 
> >
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Anthony Nadalin]

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

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

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

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

As I said I support the work.

Phil

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

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

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

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

[Brian Campbell]

I support the adoption of this draft by the working group.

I don't think an immediate WGLC was expected here.

On Wed, Apr 6, 2016 at 4:06 PM, Phil Hunt (IDM) 
wrote:

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

Re: [OAUTH-WG] Cross-Area Review Request for RDAP Authentication

[Hollenbeck, Scott]

Folks, this is the sequence of list messages that I mentioned at the end of 
today's meeting. Nat did reply on January 20th with "It is on my todo list but 
...". I really could use affirmation or correction from clueful people...

Scott

> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hollenbeck,
> Scott
> Sent: Tuesday, January 19, 2016 9:40 AM
> To: 'OAuth@ietf.org'
> Subject: Re: [OAUTH-WG] Cross-Area Review Request for RDAP
> Authentication
> 
> > -Original Message-
> > From: Hollenbeck, Scott
> > Sent: Monday, January 11, 2016 8:31 AM
> > To: OAuth@ietf.org
> > Subject: Cross-Area Review Request for RDAP Authentication
> >
> > I'd like to ask folks who are more familiar with OAuth than I am to
> > please review an I-D I've written that describes an approach to using
> > OpenID Connect with the Registration Data Access Protocol (RDAP, a
> > product of the WEIRDS WG). Those of you who are familiar with WHOIS
> > will understand the motivation behind the development of RDAP and the
> > benefits of being able to authenticate clients.
> >
> > The I-D can be found here:
> >
> > https://datatracker.ietf.org/doc/draft-hollenbeck-weirds-rdap-openid/
> >
> > Note that RDAP does not depend on clients using web browsers. I have
> > some text in the document that describes how to use OpenID Connect
> with
> > non-browser clients and I'd like to ensure that it all makes sense.
> 
> Can anyone help with this?
> 
> Scott
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

Re: [OAUTH-WG] OAuth 2.1

[George Fletcher]

I'd definitely prefer a single solution document to many little ones 
that have to be combined to actually build a secure solution. It's 
already getting complex with the additional specs that have been added.


Additionally, I'm not against working on OAuth 2.1.

Thanks,
George

On 4/6/16 2:06 PM, Phil Hunt (IDM) wrote:
  


Existing implementations are for the large part ok and do not need these 
mitigations.

Only the new use cases we have been discussing (configure on the fly and 
multi-as, etc) really need mitigation.

The updated by approach seems like a good way to address the new cases.

Phil


On Apr 6, 2016, at 14:35, Hannes Tschofenig  wrote:

Hi all,

today we discussed the OAuth Authorization Server Mixup draft. We were
wondering what types of threats the document should find solutions for.

We discussed various document handling approaches including
* OAuth Mix-Up and Cut-and-Paste attacks documented in separate
solution documents
* combined solution document covering the OAuth Mix-Up and the
Cut-and-Paste attacks.

Barry pointed out that these documents could update the OAuth base
specification.

As a more radical change it was also suggested to revise RFC 6749 "OAuth
2.0 Authorization Framework" and RFC 6819 "OAuth 2.0 Threat Model and
Security Considerations".

Opening up the OAuth base specification obviously raises various other
questions about cleaning up parts that go far beyond the AS mix-up and
the cut-and-paste attacks. Other specifications, such as the Open
Redirector, could be folded into such a new specification.

Derek and I would appreciate your input on this topic before we make a
decision since it has significant impact on our work.

Ciao
Hannes & Derek


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

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



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

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

[Phil Hunt (IDM)]

With the process of immediate wglc I think we should review all documents more 
thoroughly before adoption. 

As I said I support the work. 

Phil

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

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

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

[Hannes Tschofenig]

Phil,

we have discussed this concept already for years. In fact, it dates back
to the days of the OAuth base specification and the security
consideration section even talks about it.

We have had the content of this in the PoP key distribution draft and we
are now moving it into a separate document.

I am not sure how much longer you want to discuss it.

Ciao
Hannes


On 04/06/2016 08:07 PM, Phil Hunt (IDM) wrote:
> I would like to have more discussion before wg adoption. 
> 
> I support the work and am willing to help. 
> 
> Phil
> 
>> On Apr 6, 2016, at 14:25, Hannes Tschofenig  
>> wrote:
>>
>> Hi all,
>>
>> this is the call for adoption of 'Resource Indicators for OAuth 2.0', see
>> http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/
>>
>> Please let us know by April 20th whether you accept / object to the
>> adoption of this document as a starting point for work in the OAuth
>> working group.
>>
>> Note: If you already stated your opinion at the IETF meeting in Buenos
>> Aires then you don't need to re-state your opinion, if you want.
>>
>> The feedback at the BA IETF meeting was the following: ~10 persons
>> for accepting the document and 0 persons against.
>>
>> Ciao
>> Hannes & Derek
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 



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

Re: [OAUTH-WG] OAuth 2.1

[Phil Hunt (IDM)]

 

Existing implementations are for the large part ok and do not need these 
mitigations. 

Only the new use cases we have been discussing (configure on the fly and 
multi-as, etc) really need mitigation. 

The updated by approach seems like a good way to address the new cases. 

Phil

> On Apr 6, 2016, at 14:35, Hannes Tschofenig  wrote:
> 
> Hi all,
> 
> today we discussed the OAuth Authorization Server Mixup draft. We were
> wondering what types of threats the document should find solutions for.
> 
> We discussed various document handling approaches including
> * OAuth Mix-Up and Cut-and-Paste attacks documented in separate
> solution documents
> * combined solution document covering the OAuth Mix-Up and the
> Cut-and-Paste attacks.
> 
> Barry pointed out that these documents could update the OAuth base
> specification.
> 
> As a more radical change it was also suggested to revise RFC 6749 "OAuth
> 2.0 Authorization Framework" and RFC 6819 "OAuth 2.0 Threat Model and
> Security Considerations".
> 
> Opening up the OAuth base specification obviously raises various other
> questions about cleaning up parts that go far beyond the AS mix-up and
> the cut-and-paste attacks. Other specifications, such as the Open
> Redirector, could be folded into such a new specification.
> 
> Derek and I would appreciate your input on this topic before we make a
> decision since it has significant impact on our work.
> 
> Ciao
> Hannes & Derek
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

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

[Phil Hunt (IDM)]

I would like to have more discussion before wg adoption. 

I support the work and am willing to help. 

Phil

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

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

Re: [OAUTH-WG] Informal Discussion about Discovery Today at 16:20

[Hannes Tschofenig]

Hi Tony,

we use face-to-face time efficiently to get things moving forward faster.

I am sure the design team will still have enough issues to solve.

Ciao
Hannes


On 04/06/2016 07:49 PM, Anthony Nadalin wrote:
> Wasn't this the task of the design team ?
> 
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
> Sent: Wednesday, April 6, 2016 10:48 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Informal Discussion about Discovery Today at 16:20
> 
> Hi all,
> 
> during the f2f meeting today the suggestion was made to have another informal 
> discussion about OAuth discovery.
> 
> We are going to meet at 16:20 today at the **IETF registration desk**.
> William is trying to find a meeting room for us.
> 
> Please respond to me privately about this event, if you have feedback.
> 
> Ciao
> Hannes
> 



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

Re: [OAUTH-WG] Informal Discussion about Discovery Today at 16:20

[Anthony Nadalin]

Wasn't this the task of the design team ?

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

Hi all,

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

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

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

Ciao
Hannes

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

[OAUTH-WG] Informal Discussion about Discovery Today at 16:20

[Hannes Tschofenig]

Hi all,

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

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

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

Ciao
Hannes



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

[OAUTH-WG] Meeting Minutes

[Hannes Tschofenig]

Leif was so nice to take meeting notes during the OAuth meeting today
and they have been uploaded to:
https://www.ietf.org/proceedings/95/minutes/minutes-95-oauth

Please take a look at them and let me know if they are incorrect or need
to be extended.

Ciao
Hannes



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

[OAUTH-WG] OAuth 2.1

[Hannes Tschofenig]

Hi all,

today we discussed the OAuth Authorization Server Mixup draft. We were
wondering what types of threats the document should find solutions for.

We discussed various document handling approaches including
 * OAuth Mix-Up and Cut-and-Paste attacks documented in separate
solution documents
 * combined solution document covering the OAuth Mix-Up and the
Cut-and-Paste attacks.

Barry pointed out that these documents could update the OAuth base
specification.

As a more radical change it was also suggested to revise RFC 6749 "OAuth
2.0 Authorization Framework" and RFC 6819 "OAuth 2.0 Threat Model and
Security Considerations".

Opening up the OAuth base specification obviously raises various other
questions about cleaning up parts that go far beyond the AS mix-up and
the cut-and-paste attacks. Other specifications, such as the Open
Redirector, could be folded into such a new specification.

Derek and I would appreciate your input on this topic before we make a
decision since it has significant impact on our work.

Ciao
Hannes & Derek




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

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

[Hannes Tschofenig]

Hi all,

this is the call for adoption of 'Resource Indicators for OAuth 2.0', see
http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/

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

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

The feedback at the BA IETF meeting was the following: ~10 persons
for accepting the document and 0 persons against.

Ciao
Hannes & Derek



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

[OAUTH-WG] Design Team on "OAuth Discovery"

[Hannes Tschofenig]

Hi all,

today at the face-to-face meeting we decided to create a design team to
work on the OAuth discovery spec.

This is a short term design team that will report back to the group at
the virtual interim meeting end of May/beginning of June.

There are three input documents:



-  OAuth 2.0 Authorization Server Discovery Metadata
https://datatracker.ietf.org/doc/draft-ietf-oauth-discovery/

-  OAuth Response Metadata
https://datatracker.ietf.org/doc/draft-sakimura-oauth-meta/

-  OAuth 2.0 Bound Configuration Lookup
https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00



The following persons volunteered to be part of this design team:
* Phil, Mike, Nat, John, Brian, Dick, Tony

We will schedule conference calls to progress the work.

If you are interested to join as well let me/us know.


Ciao
Hannes & Derek



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

[OAUTH-WG] afternoon oauth ietf meeting

[Kim, William G]

Will the 2nd OAuth meeting this afternoon happen in a room with remote support? 
Are there any options to be able to remotely listen in to this discussion?

-William

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

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

[Brian Campbell]

OpenID ... ?

On Wed, Apr 6, 2016 at 9:59 AM, Anthony Nadalin 
wrote:

> Good question, since SCIM does not really provide an authorization model
> and Oauth does not do provisioning this is sort of caught in the middle, so
> if I had to pick I would pick Oauth as this is a generic server to server
> issue
>
>
>
> *From:* Hardt, Dick [mailto:d...@amazon.com]
> *Sent:* Wednesday, April 6, 2016 5:52 AM
> *To:* Anthony Nadalin 
> *Cc:* Gil Kirkpatrick ; Nat Sakimura <
> n-sakim...@nri.co.jp>; Phil Hunt (IDM) ;
> s...@ietf.org; oauth@ietf.org
> *Subject:* Re: [scim] [OAUTH-WG] Simple Federation Deployment
>
>
>
> Sounds like there is interest.
>
>
>
> SCIM or OAUTH?
>
> -- Dick
>
>
> On Apr 6, 2016, at 8:57 AM, Anthony Nadalin  wrote:
>
> I would be interested also
>
>
>
> Sent from my Windows 10 phone
>
>
>
> *From: *Gil Kirkpatrick 
> *Sent: *Wednesday, April 6, 2016 4:16 AM
> *To: *'Nat Sakimura' ; 'Hardt, Dick'
> ; 'Phil Hunt (IDM)' 
> *Cc: *s...@ietf.org; oauth@ietf.org
> *Subject: *Re: [scim] [OAUTH-WG] Simple Federation Deployment
>
>
>
> That’s an issue we’re facing as well. Definitely interested.
>
>
>
> -gil
>
>
>
> *From:* OAuth [mailto:oauth-boun...@ietf.org ] *On
> Behalf Of *Nat Sakimura
> *Sent:* Wednesday, April 6, 2016 4:57 PM
> *To:* 'Hardt, Dick' ; 'Phil Hunt (IDM)' <
> phil.h...@oracle.com>
> *Cc:* s...@ietf.org; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] [scim] Simple Federation Deployment
>
>
>
> +1 for removing the manual cut-n-pastes!
>
>
>
> Nat
>
>
>
> --
>
> PLEASE READ :This e-mail is confidential and intended for the
>
> named recipient only. If you are not an intended recipient,
>
> please notify the sender  and delete this e-mail.
>
>
>
> *From:* scim [mailto:scim-boun...@ietf.org ] *On
> Behalf Of *Hardt, Dick
> *Sent:* Wednesday, April 6, 2016 7:26 AM
> *To:* Phil Hunt (IDM) 
> *Cc:* s...@ietf.org; oauth@ietf.org
> *Subject:* Re: [scim] Simple Federation Deployment
>
>
>
> I’m talking about removing manual steps in what happens today where
> configuring a SaaS app at an IdP (such as Google, Azure, Ping, Octa)
> requires is a bunch of cutting and pasting of access tokens / keys / certs
> and doing a bunch of  config that is error prone and unique for each
> relationship.
>
>
>
> Don’t want to solve on the thread … looking to see if there is interest!
>
>
>
> On 4/5/16, 7:11 PM, someone claiming to be "scim on behalf of Phil Hunt
> (IDM)"  wrote:
>
>
>
> Is the idp the center of all things for these users?
>
>
>
> Usually you have a provisioning system that coordinates state and uses
> things like scim connectors to do this.
>
>
>
> Another approach from today would be to pass a scim event to the remote
> provider which then decides what needs to be done to facilitate the thingd
> you describe.
>
>
>
> Iow. Either the idp (sender) or the sp (receiver) have a provisioning
> system to do this.
>
>
>
> The solution and the simplicity depends on where the control needs to be.
>
> Phil
>
>
> On Apr 5, 2016, at 18:59, Hardt, Dick  wrote:
>
> Use case: An admin for an organization would like to enable her users to
> access a SaaS application at her IdP.
>
>
>
> User experience:
>
>1. Admin authenticates to IdP in browser
>2. Admin selects SaaS app to federate with from list at IdP
>3. IdP optionally presents config options
>4. IdP redirects Admin to SaaS app
>5. Admin authenticates to SaaS app
>6. SaaS app optionally gathers config options
>7. SaaS app redirects admin to IdP
>8. IdP confirms successful federation => OIDC / SAML and SCIM are now
>configured and working between IdP and SaaS App
>
> Who else is interested in solving this?
>
>
>
> Is there interest in working on this in either SCIM or OAUTH Wgs?
>
>
>
> Any one in BA interested in meeting on this topic this week?
>
>
>
> — Dick
>
> ___
> scim mailing list
> s...@ietf.org
> https://www.ietf.org/mailman/listinfo/scim
> 
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Phil Hunt]

I think it is worth discussing in oauth wg.

While SCIM has issues, I think it represents a broader use case that other 
applications have that are deployed widely.

Phil

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






> On Apr 6, 2016, at 9:52 AM, Hardt, Dick  wrote:
> 
> Sounds like there is interest.
> 
> SCIM or OAUTH?
> 
> -- Dick
> 
> On Apr 6, 2016, at 8:57 AM, Anthony Nadalin  > wrote:
> 
>> I would be interested also
>>  
>> Sent from my Windows 10 phone
>>  
>> From: Gil Kirkpatrick 
>> Sent: Wednesday, April 6, 2016 4:16 AM
>> To: 'Nat Sakimura' ; 'Hardt, Dick' 
>> ; 'Phil Hunt (IDM)' 
>> Cc: s...@ietf.org ; oauth@ietf.org 
>> 
>> Subject: Re: [scim] [OAUTH-WG] Simple Federation Deployment
>>  
>> That’s an issue we’re facing as well. Definitely interested.
>>  
>> -gil
>>  
>> From: OAuth [mailto:oauth-boun...@ietf.org ] 
>> On Behalf Of Nat Sakimura
>> Sent: Wednesday, April 6, 2016 4:57 PM
>> To: 'Hardt, Dick' >; 'Phil Hunt 
>> (IDM)' >
>> Cc: s...@ietf.org ; oauth@ietf.org 
>> 
>> Subject: Re: [OAUTH-WG] [scim] Simple Federation Deployment
>>  
>> +1 for removing the manual cut-n-pastes! <>
>>  
>> Nat
>>  
>> --
>> PLEASE READ :This e-mail is confidential and intended for the
>> named recipient only. If you are not an intended recipient,
>> please notify the sender  and delete this e-mail.
>>  
>> From: scim [mailto:scim-boun...@ietf.org ] On 
>> Behalf Of Hardt, Dick
>> Sent: Wednesday, April 6, 2016 7:26 AM
>> To: Phil Hunt (IDM) >
>> Cc: s...@ietf.org ; oauth@ietf.org 
>> 
>> Subject: Re: [scim] Simple Federation Deployment
>>  
>> I’m talking about removing manual steps in what happens today where 
>> configuring a SaaS app at an IdP (such as Google, Azure, Ping, Octa) 
>> requires is a bunch of cutting and pasting of access tokens / keys / certs 
>> and doing a bunch of  config that is error prone and unique for each 
>> relationship.
>>  
>> Don’t want to solve on the thread … looking to see if there is interest!
>>  
>> On 4/5/16, 7:11 PM, someone claiming to be "scim on behalf of Phil Hunt 
>> (IDM)"  on behalf of 
>> phil.h...@oracle.com > wrote:
>>  
>> Is the idp the center of all things for these users?
>>  
>> Usually you have a provisioning system that coordinates state and uses 
>> things like scim connectors to do this. 
>>  
>> Another approach from today would be to pass a scim event to the remote 
>> provider which then decides what needs to be done to facilitate the thingd 
>> you describe. 
>>  
>> Iow. Either the idp (sender) or the sp (receiver) have a provisioning system 
>> to do this. 
>>  
>> The solution and the simplicity depends on where the control needs to be. 
>> 
>> Phil
>> 
>> On Apr 5, 2016, at 18:59, Hardt, Dick > > wrote:
>> 
>> Use case: An admin for an organization would like to enable her users to 
>> access a SaaS application at her IdP. 
>>  
>> User experience: 
>> Admin authenticates to IdP in browser
>> Admin selects SaaS app to federate with from list at IdP
>> IdP optionally presents config options
>> IdP redirects Admin to SaaS app
>> Admin authenticates to SaaS app
>> SaaS app optionally gathers config options
>> SaaS app redirects admin to IdP
>> IdP confirms successful federation => OIDC / SAML and SCIM are now 
>> configured and working between IdP and SaaS App
>> Who else is interested in solving this?
>>  
>> Is there interest in working on this in either SCIM or OAUTH Wgs?
>>  
>> Any one in BA interested in meeting on this topic this week?
>>  
>> — Dick
>> ___
>> scim mailing list
>> s...@ietf.org 
>> https://www.ietf.org/mailman/listinfo/scim 
>> 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Anthony Nadalin]

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

From: Hardt, Dick [mailto:d...@amazon.com]
Sent: Wednesday, April 6, 2016 5:52 AM
To: Anthony Nadalin 
Cc: Gil Kirkpatrick ; Nat Sakimura 
; Phil Hunt (IDM) ; s...@ietf.org; 
oauth@ietf.org
Subject: Re: [scim] [OAUTH-WG] Simple Federation Deployment

Sounds like there is interest.

SCIM or OAUTH?

-- Dick

On Apr 6, 2016, at 8:57 AM, Anthony Nadalin 
> wrote:
I would be interested also

Sent from my Windows 10 phone

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

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

-gil

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

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

Nat

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

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

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

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

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

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

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

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

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

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

Phil

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

User experience:

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

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

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

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

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

[Anthony Nadalin]

I would be interested also

Sent from my Windows 10 phone

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

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

-gil

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

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

Nat

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

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

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

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

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

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

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

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

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

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

Phil

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

User experience:

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

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

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

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

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

[Gil Kirkpatrick]

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

 

-gil

 

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

 

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

 

Nat

 

--

PLEASE READ :This e-mail is confidential and intended for the

named recipient only. If you are not an intended recipient,

please notify the sender  and delete this e-mail.

 

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

 

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

 

Don’t want to solve on the thread … looking to see if there is interest!

 

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

 

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

 

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

 

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

 

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

 

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

Phil


On Apr 5, 2016, at 18:59, Hardt, Dick  
> wrote:

Use case: An admin for an organization would like to enable her users to access 
a SaaS application at her IdP. 

 

User experience: 

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

Who else is interested in solving this?

 

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

 

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

 

— Dick

___
scim mailing list
s...@ietf.org  
https://www.ietf.org/mailman/listinfo/scim

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

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

[Nat Sakimura]

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

 

Nat

 

--

PLEASE READ :This e-mail is confidential and intended for the

named recipient only. If you are not an intended recipient,

please notify the sender  and delete this e-mail.

 

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

 

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

 

Don’t want to solve on the thread … looking to see if there is interest!

 

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

 

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

 

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

 

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

 

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

 

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

Phil


On Apr 5, 2016, at 18:59, Hardt, Dick  
> wrote:

Use case: An admin for an organization would like to enable her users to access 
a SaaS application at her IdP. 

 

User experience: 

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

Who else is interested in solving this?

 

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

 

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

 

— Dick

___
scim mailing list
s...@ietf.org  
https://www.ietf.org/mailman/listinfo/scim

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