Subject: [scim] signed JSON objects instead of OAuth 2?

From: Bill Mills <[email-masked]>
Date: Wed, 30 Apr 2014 12:05:27 -0700

What does the group think of using signed JSON objects for authentication rather than OAuth?

-bill

--------------------------------
William J. Mills
Technical Yahoo!

---

From: Phil Hunt <[email-masked]>
Date: Tue, 6 May 2014 10:19:26 -0700

Well it is out of scope. 

But I don't see why scim couldn't be the api for an authentication system that generates the assertion (including authen date etc). 

Phil

> On Apr 30, 2014, at 12:05, Bill Mills <[email-masked]> wrote:
> 
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Erik Wahlström <[email-masked]>
Date: Tue, 6 May 2014 17:34:23 +0000

+1 on out of scope.

Sent from my iPad

On 6 maj 2014, at 10:20, "Phil Hunt" <[email-masked]<mailto:[email-masked]>> wrote:

Well it is out of scope.

Phil

On Apr 30, 2014, at 12:05, Bill Mills <[email-masked]<mailto:[email-masked]>> wrote:

-bill

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

---

From: Bill Mills <[email-masked]>
Date: Tue, 6 May 2014 10:46:41 -0700 (PDT)

Sure it's out of scope, but it needs solving in broader the context.
On Tuesday, May 6, 2014 10:34 AM, Erik Wahlström <[email-masked]> wrote:
 
+1 on out of scope.

Sent from my iPad

On 6 maj 2014, at 10:20, "Phil Hunt" <[email-masked]> wrote:

Well it is out of scope.

---

From: Kelly Grizzle <[email-masked]>
Date: Tue, 6 May 2014 19:05:31 +0000

A service provider has the option to implement any type of authn that they want (see section 2 of the API draft below).  Is there something specific that you are wanting to add, Bill?  Is there a spec for a signed JSON object that you have in mind?

http://tools.ietf.org/html/draft-ietf-scim-api-04#section-2

   The SCIM protocol does not define a scheme for authentication and
   authorization therefore implementers are free to choose mechanisms
   appropriate to their use cases.  The choice of authentication

   mechanism will impact interoperability.  It is RECOMMENDED that

   clients be implemented in such a way that new authentication schemes

   can be deployed.  Implementers SHOULD support existing authentication

   /authorization schemes.  In particular, OAuth2[RFC6750] is

   RECOMMENDED.  Appropriate security considerations of the selected

   authentication and authorization schemes SHOULD be taken.

The service provider specifies its supported authn in the authenticationSchemes attribute of /ServiceProviderConfig (http://tools.ietf.org/html/draft-ietf-scim-core-schema-04#section-9).

--Kelly

From: scim [mailto:[email-masked]] On Behalf Of Bill Mills
Sent: Tuesday, May 06, 2014 12:47 PM
To: Erik Wahlström; Phil Hunt
Cc: Scim WG; Bill Mills
Subject: Re: [scim] signed JSON objects instead of OAuth 2?

Sure it's out of scope, but it needs solving in broader the context.
On Tuesday, May 6, 2014 10:34 AM, Erik Wahlström <[email-masked]<mailto:[email-masked]>> wrote:
+1 on out of scope.

Sent from my iPad

Phil

-bill

---

From: Phil Hunt <[email-masked]>
Date: Tue, 6 May 2014 12:09:37 -0700

There are two different issues.

1.  How a client authenticates to scim (section 2 below)
2.  How a client uses scim for authenticating users.

IMHO… for 1, a SCIM service is just like any other web service and is authenticate by normal HTTP techniques.

For 2, a client can be an authentication service that calls into scim to validate claims and obtain role and other information used in an authentication process.

Phil

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