Subject: [scim] Draft charter - v4

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Wed, 14 Mar 2012 22:24:07 -0500

Trey, Kelly, and I huddled over for a few minutes today and added some
text to the version Eliot sent out yesterday.  We tried to address the
questions Eliot raised and remove some of the ambiguous text based on
the email discussions.  Please review and send your comments/feedback.

Cheers,

Morteza

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 15 Mar 2012 10:09:03 +0000

> the email discussions.  Please review and send your comments/feedback.

Your proposal says:

"The group considers the following out of scope for this group:
      Defining new authentication schemes
      Defining new policy/authorization schemes
      Defining how SCIM implementations define and implement
        authorization"

The first two are fine, and entirely sensible. I don't
get the 3rd.

scim will presumably define some messages that can be sent,
e.g.:

   Alice->Bob: Here's Charlie's new password

I don't see how you'll be secure if anyone that's
authenticated can reset Charlie's password, so some
authorization is clearly needed.

I don't see how you'll get interop if Alice and Bob
don't have a common way to determine that Alice is ok
to reset Charlie's password.

What's the reason to try leave authorization for such
scim messages out of scope?

S

---

From: "Brenner, Michael Ralf (Michael)" <[email-masked]>
Date: Thu, 15 Mar 2012 08:05:03 -0500

The way I understood the proposed scope is that SCIM WG itself will not provide deliverables that recommend specific IMPLEMENTATIONS for authorization. I did not understand it as "it's not necessary or important", rather that it is the scope of other groups.

Not sure if anything is needed, but if so - we could consider adding: "... while not preventing the use of different authorization mechanisms". This will raise the awareness to ensure that was is specified works in conjunction with OAuth and/or other mechanisms.

Michael 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Thursday, March 15, 2012 6:09 AM
To: Morteza Ansari (moransar)
Cc: [email-masked]
Subject: Re: [scim] Draft charter - v4

Your proposal says:

S
_______________________________________________
scim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/scim

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 15 Mar 2012 13:10:51 +0000

I'm not sure what exactly you mean by implementation.

RFCs of course don't provide code for stuff like this.

But to get interop, both sides need to (be able to)
use the same thing. So RFCs do usually specify a "MUST
implement" set of features for stuff like this.

If one did OAuth and one kerberos then that'd not work.
(In either case there'd likely be work to say just how
to use the underlying scheme.)

Seems to me this wg would need to pick something here
and maybe do some profiling, so that authorization
decisions can be made in a secure and interoperable
manner.

S

---

From: "Brenner, Michael Ralf (Michael)" <[email-masked]>
Date: Thu, 15 Mar 2012 08:21:23 -0500

Stephen,

When using "implementations" in my suggestion I was referring to the wording in point 3 that you had an issue with: "Defining how SCIM implementations define and implement authorization".

In the current SCIM specs, the wording is consistent with what I suggested (although I don't think it is strictly necessary to add anything, as mentioned in my previous message). Section 2. Authentication and Authorization states make a series of recommendations, among others a strong recommendation for support for OAuth 2 Bearer Token, but the recommendations are intended to the IMPLEMENTERS (to support existing authentication/authorization schemes, among them OAuth 2). However they stop short of mandating any authentication/authorization scheme, which I think is the right approach.

Michael
-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Thursday, March 15, 2012 9:11 AM
To: Brenner, Michael Ralf (Michael)
Cc: Morteza Ansari (moransar); [email-masked]
Subject: Re: [scim] Draft charter - v4

S

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 15 Mar 2012 13:30:45 +0000

So I think we are using terms slightly differently. But
that's ok and something that's not uncommon when different
folks get involved in a BoF coming from different
backgrounds.

Mandating the ability to support OAuth may be quite
sensible in this case. In any case, OAuth is probably
fairly clearly something that'd need to be considered.

Not doing that (or some equivalent) would seem to break
interop and require pairwise agreements as to how to do
authorization which would IMO be broken.

S

---

From: "Brenner, Michael Ralf (Michael)" <[email-masked]>
Date: Thu, 15 Mar 2012 08:37:46 -0500

I would not go as far as "mandating the use of OAuth" as part of the charter of SCIM group, mainly because that may be then interpreted by some as "OAuth would be the only authorization mechanism that SCIM supports". But I do agree that SCIM MUST work in conjunction with AT LEAST OAuth (while not excluding other authorization mechanisms). It so happens that using OAuth 2 Bearer Token makes this relatively painless and un-intrusive to the scope of SCIM group to fulfill, IMHO.

Michael 

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Thursday, March 15, 2012 9:31 AM
To: Brenner, Michael Ralf (Michael)
Cc: [email-masked]; Morteza Ansari (moransar)
Subject: Re: [scim] Draft charter - v4

S

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 15 Mar 2012 13:47:40 +0000

Note: I'm talking about mandatory-to-implement not mandatory-
to-use. Those differ. The former allows for interop. regardless
of where you get your code (if done well of course:-)

In any case, I do believe this putative WG does need to specify
how authorization is to be handled, which conflicts with the
original mail to which I responded.

S

---

From: "Brenner, Michael Ralf (Michael)" <[email-masked]>
Date: Thu, 15 Mar 2012 09:02:25 -0500

I don't think SCIM has to mandatorily implement (implement as in "defining as part of the SCIM specs") anything in order to work with Oath 2 Bearer Token. Otherwise we end up defining vendor's implementation of SCIM & OAuth. A vendor that would implement BOTH the SCIM and OAuth 2.0 specifications would have to support in SCIM requests the passing of a (separately and previously) obtained OAuth 2.0 token, via an HTTP header. IMHO, this is orthogonal to the definitions in SCIM specs themselves.
Michael

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Thursday, March 15, 2012 9:48 AM
To: Brenner, Michael Ralf (Michael)
Cc: [email-masked]; Morteza Ansari (moransar)
Subject: Re: [scim] Draft charter - v4

S

---

From: Trey Drake <[email-masked]>
Date: Thu, 15 Mar 2012 09:12:26 -0500

The intent is exactly that - we do not intend to mandate specific authorization schemes though we do intend to recommend.  In particular, the draft submission will recommend use of OAuth2 Bearer Token.  Unfortunately, we missed the draft submission date, hence the protocol draft that makes the point clear is unavailable. 

The question, as I interpret, is (using the case below): do we need to specify a scheme whereby Alice has a priori knowledge of what Alice has access to or do we remain silent and simply specify what must happen when an unauthorized Alice attempts to modify Bob.  The current thinking is the latter.  

Thanks,
Trey

---

From: "Brenner, Michael Ralf (Michael)" <[email-masked]>
Date: Thu, 15 Mar 2012 09:15:48 -0500

This matches my understanding.
Thanks,
Michael

-----Original Message-----
From: Trey Drake [mailto:[email-masked]] 
Sent: Thursday, March 15, 2012 10:12 AM
To: Brenner, Michael Ralf (Michael)
Cc: Stephen Farrell; [email-masked]; Morteza Ansari (moransar)
Subject: Re: [scim] Draft charter - v4

Thanks,
Trey

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 15 Mar 2012 14:15:59 +0000

> The question, as I interpret, is (using the case below): do we need to specify a scheme whereby Alice has a priori knowledge of what Alice has access to or do we remain silent and simply specify wh…

You need to tell the developer of Alice's code how to write the code
so Alice can demonstrate that she is authorized to all the potential
Bob's in the world for which she is in fact authorized to do whatever
operation she's trying.

Whether or not Alice needs to be able to ask Bob what she's allowed
to do is a different issue entirely.

S

---

From: "Diodati,Mark" <[email-masked]>
Date: Thu, 15 Mar 2012 14:25:07 +0000

+1 on Trey's assessment.

Also, SCIM should not mandate OAuth. There are other mechanisms for authorization for authentication. Particularly, some folks will want to use certificates (perhaps backed with private key stored in an HSM) and (potentially) passwords for testing or lower assurance services.

Mark

-----Original Message-----
From: Trey Drake [mailto:[email-masked]]
Sent: Thursday, March 15, 2012 9:12 AM
To: Brenner, Michael Ralf (Michael)
Cc: [email-masked]; Morteza Ansari (moransar); Stephen Farrell
Subject: Re: [scim] Draft charter - v4

Thanks,
Trey

>>> scim messages out of scope?

________________________________

This e-mail message, including any attachments, is for the sole use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Gartner makes no warranty that this e-mail is error or virus free.

---

From: "Salvatore D'Agostino" <[email-masked]>
Date: Thu, 15 Mar 2012 10:53:29 -0400

+1 Trey

Is this no mandate for any client authN type or token type?

Sal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Diodati,Mark
Sent: Thursday, March 15, 2012 10:25 AM
To: Trey Drake; Brenner, Michael Ralf (Michael)
Cc: [email-masked]; Morteza Ansari (moransar); Stephen Farrell
Subject: Re: [scim] Draft charter - v4

+1 on Trey's assessment.

Also, SCIM should not mandate OAuth. There are other mechanisms for
authorization for authentication. Particularly, some folks will want to use
certificates (perhaps backed with private key stored in an HSM) and
(potentially) passwords for testing or lower assurance services.

Mark

-----Original Message-----
From: Trey Drake [mailto:[email-masked]]
Sent: Thursday, March 15, 2012 9:12 AM
To: Brenner, Michael Ralf (Michael)
Cc: [email-masked]; Morteza Ansari (moransar); Stephen Farrell
Subject: Re: [scim] Draft charter - v4

The intent is exactly that - we do not intend to mandate specific
authorization schemes though we do intend to recommend.  In particular, the
draft submission will recommend use of OAuth2 Bearer Token.  Unfortunately,
we missed the draft submission date, hence the protocol draft that makes the
point clear is unavailable.

The question, as I interpret, is (using the case below): do we need to
specify a scheme whereby Alice has a priori knowledge of what Alice has
access to or do we remain silent and simply specify what must happen when an
unauthorized Alice attempts to modify Bob.  The current thinking is the
latter.

Thanks,
Trey

On Mar 15, 2012, at 8:37 AM, Brenner, Michael Ralf (Michael) wrote:

> I would not go as far as "mandating the use of OAuth" as part of the
charter of SCIM group, mainly because that may be then interpreted by some
as "OAuth would be the only authorization mechanism that SCIM supports". But
I do agree that SCIM MUST work in conjunction with AT LEAST OAuth (while not
excluding other authorization mechanisms). It so happens that using OAuth 2
Bearer Token makes this relatively painless and un-intrusive to the scope of
SCIM group to fulfill, IMHO.
> So I think we are using terms slightly differently. But that's ok and 
> something that's not uncommon when different folks get involved in a 
> BoF coming from different backgrounds.
>
> Mandating the ability to support OAuth may be quite sensible in this 
> case. In any case, OAuth is probably fairly clearly something that'd 
> need to be considered.
>
> Not doing that (or some equivalent) would seem to break interop and 
> require pairwise agreements as to how to do authorization which would 
> IMO be broken.
>
> S
>
>> When using "implementations" in my suggestion I was referring to the
wording in point 3 that you had an issue with: "Defining how SCIM
implementations define and implement authorization".
>>
>> In the current SCIM specs, the wording is consistent with what I
suggested (although I don't think it is strictly necessary to add anything,
as mentioned in my previous message). Section 2. Authentication and
Authorization states make a series of recommendations, among others a strong
recommendation for support for OAuth 2 Bearer Token, but the recommendations
are intended to the IMPLEMENTERS (to support existing
authentication/authorization schemes, among them OAuth 2). However they stop
short of mandating any authentication/authorization scheme, which I think is
the right approach.
>> But to get interop, both sides need to (be able to) use the same 
>> thing. So RFCs do usually specify a "MUST implement" set of features 
>> for stuff like this.
>>
>> (In either case there'd likely be work to say just how to use the 
>> underlying scheme.)
>>
>> Seems to me this wg would need to pick something here and maybe do 
>> some profiling, so that authorization decisions can be made in a 
>> secure and interoperable manner.
>>
>> S
>>
>>> The way I understood the proposed scope is that SCIM WG itself will not
provide deliverables that recommend specific IMPLEMENTATIONS for
authorization. I did not understand it as "it's not necessary or important",
rather that it is the scope of other groups.
>>>
>>> Not sure if anything is needed, but if so - we could consider adding:
"... while not preventing the use of different authorization mechanisms".
This will raise the awareness to ensure that was is specified works in
conjunction with OAuth and/or other mechanisms.
>>>> Trey, Kelly, and I huddled over for a few minutes today and added 
>>>> some text to the version Eliot sent out yesterday.  We tried to 
>>>> address the questions Eliot raised and remove some of the ambiguous 
>>>> text based on the email discussions.  Please review and send your
comments/feedback.
>>> The first two are fine, and entirely sensible. I don't get the 3rd.
>>>
>>> I don't see how you'll be secure if anyone that's authenticated can 
>>> reset Charlie's password, so some authorization is clearly needed.
>>>
>>> I don't see how you'll get interop if Alice and Bob don't have a 
>>> common way to determine that Alice is ok to reset Charlie's 
>>> password.
>>>
>>> What's the reason to try leave authorization for such scim messages 
>>> out of scope?
>>>
>>> S

This e-mail message, including any attachments, is for the sole use of the
person to whom it has been sent, and may contain information that is
confidential or legally protected. If you are not the intended recipient or
have received this message in error, you are not authorized to copy,
distribute, or otherwise use this message or its attachments. Please notify
the sender immediately by return e-mail and permanently delete this message
and any attachments. Gartner makes no warranty that this e-mail is error or
virus free.
_______________________________________________
scim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/scim

---

From: Trey Drake <[email-masked]>
Date: Thu, 15 Mar 2012 10:25:37 -0500

I'm sure this will (once again) be heavily debated once the group is formed.  In the past the balancing act was bent towards pragmatism; i.e., what can organizations actually roll out in the foreseeable future?  The answer is/was recommendation for OAuth bearer tokens, language encouraging service providers to remain flexible w.r.t. authN/Z schemes, and a facility for discovering the authentication schemes supported by the service provider.  The latter  enables a developer/consumer the ability to poke through and select an appropriate scheme.

Thanks,
Trey

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 15 Mar 2012 14:12:20 -0600

On 3/15/12 9:25 AM, Trey Drake wrote:
> I'm sure this will (once again) be heavily debated once the group is
> formed.  In the past the balancing act was bent towards pragmatism;
> i.e., what can organizations actually roll out in the foreseeable
> future?  The answer is/was recommendation for OAuth bearer tokens,
> language encouraging service providers to remain flexible w.r.t.
> authN/Z schemes, and a facility for discovering the authentication
> schemes supported by the service provider.  The latter  enables a
> developer/consumer the ability to poke through and select an
> appropriate scheme.

First, without my sponsoring AD hat on, I agree with Stephen that
there's confusion about terminology here. In IETF protocol specs, we
tend to differentiate among two things:

1. Mandatory-to-implement. This means that if you're writing a code
library, a server, or a client, your code MUST support the feature.

2. Mandatory-to-deploy. This means that all service providers MUST
actually use the code in those implementations.

We typically talk only about mandatory-to-implement. This enables
service providers to be flexible in their deployments while still
ensuring that we have a baseline for interoperability. Everything you
guys have done to enable discovery of supported mechanisms fits right in
with this way of specifying the protocol. Please also understand that
mandatory-to-implement does *not* mean that you can't implement other
mechanisms. It just means that everyone will have at least one mechanism
in common.

Second, with my sponsoring AD hat on, I strongly encourage folks to
specify a mandatory-to-implement authorization technology, for the
reasons that Stephen outlined.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Thu, 15 Mar 2012 15:35:14 -0500

Great discussion everyone. I think we are all on the same page (maybe with the exception of mandatory to implement which I am sure we will have many discussions on if the WG is created).  The question is how can we improve the wording of the third bullet to clearly say what we intended to say?  Does anyone have a suggestion?

Cheers,
Morteza

-----Original Message-----
From: Peter Saint-Andre [mailto:[email-masked]] 
Sent: Thursday, March 15, 2012 1:12 PM
To: Trey Drake
Cc: Salvatore D'Agostino; 'Brenner, Michael Ralf (Michael)'; 'Diodati, Mark'; 'Stephen Farrell'; Morteza Ansari (moransar); [email-masked]
Subject: Re: [scim] Draft charter - v4

> developer/consumer the ability to poke through and select an 

First, without my sponsoring AD hat on, I agree with Stephen that there's confusion about terminology here. In IETF protocol specs, we tend to differentiate among two things:

1. Mandatory-to-implement. This means that if you're writing a code library, a server, or a client, your code MUST support the feature.

2. Mandatory-to-deploy. This means that all service providers MUST actually use the code in those implementations.

We typically talk only about mandatory-to-implement. This enables service providers to be flexible in their deployments while still ensuring that we have a baseline for interoperability. Everything you guys have done to enable discovery of supported mechanisms fits right in with this way of specifying the protocol. Please also understand that mandatory-to-implement does *not* mean that you can't implement other mechanisms. It just means that everyone will have at least one mechanism in common.

Second, with my sponsoring AD hat on, I strongly encourage folks to specify a mandatory-to-implement authorization technology, for the reasons that Stephen outlined.

Peter

--
Peter Saint-Andre
https://stpeter.im/

---

From: Trey Drake <[email-masked]>
Date: Thu, 15 Mar 2012 15:36:09 -0500

I hear you.  Now that Peter has expedited and posted (thanks!) a protocol draft (http://www.ietf.org/id/draft-scim-api-00.txt) we have something more concrete to talk to.  See section 2 (Authentication and Authorization).  

Thanks,
Trey

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 15 Mar 2012 14:41:52 -0600

On 3/15/12 2:36 PM, Trey Drake wrote:
> I hear you.  Now that Peter has expedited and posted (thanks!) a
> protocol draft (http://www.ietf.org/id/draft-scim-api-00.txt) we have
> something more concrete to talk to.  See section 2 (Authentication
> and Authorization).

A more hyperlinked version is here:

http://tools.ietf.org/html/draft-scim-api-00

Things like http://tools.ietf.org/html/draft-scim-api-00#section-2 can
be easier to reference. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 15 Mar 2012 14:51:35 -0600

With my individual contributor hat on. I think.

On 3/15/12 2:35 PM, Morteza Ansari (moransar) wrote:
> Great discussion everyone. I think we are all on the same page (maybe
> with the exception of mandatory to implement which I am sure we will
> have many discussions on if the WG is created).  The question is how
> can we improve the wording of the third bullet to clearly say what we
> intended to say?  Does anyone have a suggestion?

Remove the third bullet? :)

Earlier in the charter we already say that we will be "applying existing
authentication, authorization, and privacy models". That's a fine thing.
It's also good that we're not expecting a SCIM working group (if formed)
to define new authentication and authorization technologies. However,
not providing a baseline MTI technology for either of those core
security features doesn't appear to "improve security of the overall
system", as the charter also says. I can assure you that Stephen isn't
the only one who will be hammering the group on this point. IMHO it's
better to agree that we need an MTI authorization technology, and fight
later over which technology is best to choose as a baseline.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Brenner, Michael Ralf (Michael)" <[email-masked]>
Date: Thu, 15 Mar 2012 16:43:14 -0500

Peter, all:

We are in agreement with respect to "1. Mandatory-to-implement. This means that if you're writing a code 
> library, a server, or a client, your code MUST support the feature."

I also agree that SCIM should work in conjunction with different authorization mechanism, in particular OAuth 2.0.

But when it comes to for example using OAuth 2.0, does the above really "Mandatory-to-implement" really mean this has to be captured in SCIM spec? Depending on how this is worded, it could be interpreted as "SCIM spec does not work UNLESS one implements OAuth 2.0", which I don't think is the case.

It is therefore important how such "mandatory-to-implement" is worded. If we intend to normatively reference OAuth 2.0, that would be perfectly fine however.

Michael 

-----Original Message-----
From: Peter Saint-Andre [mailto:[email-masked]] 
Sent: Thursday, March 15, 2012 4:12 PM
To: Trey Drake
Cc: Salvatore D'Agostino; Brenner, Michael Ralf (Michael); 'Diodati, Mark'; 'Stephen Farrell'; 'Morteza Ansari (moransar)'; [email-masked]
Subject: Re: [scim] Draft charter - v4

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 15 Mar 2012 15:54:11 -0600

<hat type='individual'/>

On 3/15/12 3:43 PM, Brenner, Michael Ralf (Michael) wrote:
> I also agree that SCIM should work in conjunction with different
> authorization mechanism, in particular OAuth 2.0.
> 
> But when it comes to for example using OAuth 2.0, does the above
> really "Mandatory-to-implement" really mean this has to be captured
> in SCIM spec? Depending on how this is worded, it could be
> interpreted as "SCIM spec does not work UNLESS one implements OAuth
> 2.0", which I don't think is the case.

No, it means someone's code can't claim compliance unless it implements
the OAuth 2.0 authorization mechanism. It could, of course, implement
other authorization mechanisms in addition.

IETF specs do this all the time. The example I'm most intimately
familiar with is XMPP. There, we use SASL (RFC 4422) for authentication,
and we mandate support for a specific SASL mechanism (SCRAM = RFC 5802)
as a baseline for intoperability. If we said "you MUST support SASL but
you can use any SASL mechanism you like", then some servers would
implement SCRAM, some DIGEST-MD5, some EXTERNAL, some PLAIN over TLS,
etc., but an XMPP client would never have any assurance that it could
log in anywhere. IETF folks consider that a bad thing, and such an
approach will simply not fly during security review later on.

Let me turn the question on its head: what are we *gaining* by saying
that implementations (*not* deployments) will *not* have a baseline
authorization method?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Brenner, Michael Ralf (Michael)" <[email-masked]>
Date: Thu, 15 Mar 2012 17:02:45 -0500

I think I did not make myself understood well.
My point is: "is this mandatory-to-implement" part affecting the way we end up defining the core SCIM features? As in "this authorization mechanism is specified as being integral part of SCIM"?

Of course there is no harm in specifying it MUST work WITH OAuth 2.0.

It looks like we have some that want to mandate-to-implement an authorization mechanism (probably OAuth 2.0), others that don't, and some (myself at least) that want to be careful about how we may mandate it, if we mandate it.

We'll sort it out eventually I'm sure.

-----Original Message-----
From: Peter Saint-Andre [mailto:[email-masked]] 
Sent: Thursday, March 15, 2012 5:54 PM
To: Brenner, Michael Ralf (Michael)
Cc: [email-masked]
Subject: Re: [scim] Draft charter - v4

<hat type='individual'/>

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Phil Hunt <[email-masked]>
Date: Thu, 15 Mar 2012 15:04:02 -0700

It seems to me that BASIC Auth should be MTI (legacy cases).

I'm a bit confused by a recommendation of OAuth2. OAuth2 issues tokens. What you mean to say is that clients should be able to use tokens such as those issued by OAuth2 or even Kerberos (or even ones issued OOB).

Phil

@independentid
www.independentid.com
[email-masked]

---

From: "Brenner, Michael Ralf (Michael)" <[email-masked]>
Date: Thu, 15 Mar 2012 17:11:08 -0500

Yes, if we refer strictly to the passing of the token in a request header, you are correct: the client should be able to include tokens (such as ...). However, the client must somehow also obtain such tokens before using them, and mechanisms for obtaining such tokens may differ.

That is why I think the wording regarding what is "mandatory-to-implement" as part of SCIM is important. If we limit it to the ability to pass authorization tokens to SCIM resources via SCIM requests, that would be OK for me.

-----Original Message-----
From: Phil Hunt [mailto:[email-masked]] 
Sent: Thursday, March 15, 2012 6:04 PM
To: Peter Saint-Andre
Cc: Brenner, Michael Ralf (Michael); [email-masked]
Subject: Re: [scim] Draft charter - v4

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Trey Drake <[email-masked]>
Date: Thu, 15 Mar 2012 17:20:15 -0500

What's meant are bearer tokens.  The original question pertained to authZ not authN which is the road we attempted to drive around.  Http Basic is a sensible authN 'punt' given TLS is required - I'm sure others will disagree.  

Thanks,
Trey

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 15 Mar 2012 17:25:18 -0600

> We'll sort it out eventually I'm sure.

Well, Stephen seemed to think you'd need authorization to determine if a
given entity was allowed to perform a given operation. For example, who
is authorized to move UserA from Domain1 to Domain2? So yes, let's
explore whether we need authorization first, then have a discussion
about whether we need an MTI mechanism for that function.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Thu, 15 Mar 2012 19:49:29 -0500

I think this is all good discussion and I think in due time we will have
to come up with decisions on both fronts (what authorization we need in
place, and what mechanism, if any needs to be mandatory to implement).
However, I don't think we need to decide on what the answer is right
now.

Going back to the charter discussion, I like Peter's suggestion of
removing the third bullet from the proposed charter.  What do others
think?  Anyone object?

Cheers,
Morteza

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peter Saint-Andre
Sent: Thursday, March 15, 2012 4:25 PM
To: Brenner, Michael Ralf (Michael)
Cc: [email-masked]
Subject: Re: [scim] Draft charter - v4

On 3/15/12 4:02 PM, Brenner, Michael Ralf (Michael) wrote:
> My point is: "is this mandatory-to-implement" part affecting the way
we end up defining the core SCIM features? As in "this authorization
mechanism is specified as being integral part of SCIM"?
> It looks like we have some that want to mandate-to-implement an
authorization mechanism (probably OAuth 2.0), others that don't, and
some (myself at least) that want to be careful about how we may mandate
it, if we mandate it.

Peter

--
Peter Saint-Andre
https://stpeter.im/

---

From: Trey Drake <[email-masked]>
Date: Thu, 15 Mar 2012 19:55:42 -0500

Makes sense to me - remove it.

---

From: "Brenner, Michael Ralf (Michael)" <[email-masked]>
Date: Thu, 15 Mar 2012 20:19:28 -0500

No doubt something that needs sorted out.
Michael

-----Original Message-----
From: Peter Saint-Andre [mailto:[email-masked]] 
Sent: Thursday, March 15, 2012 7:25 PM
To: Brenner, Michael Ralf (Michael)
Cc: [email-masked]
Subject: Re: [scim] Draft charter - v4

Peter

-- 
Peter Saint-Andre
https://stpeter.im/