Subject: [OAUTH-WG] A Proposal for Dynamic Registration

From: Justin Richer <[email-masked]>
Date: Tue, 6 Aug 2013 17:18:26 -0400

At last week's IETF meeting, there was quite a lot of talk about the 
Dynamic Registration draft as well as a few other related drafts in this 
space. I would like to propose to the group what I think would be a 
positive working structure among the different approaches that would let 
us move everything forward. The source documents in discussion here are 
the WG's Dynamic Registration (draft 14) and Phil Hunt's individual 
submission of a SCIM-based alternative with some software assertion 
components to it. I suggest we refactor these into three documents:

  - OAuth Dynamic Registration
  - SCIM-based OAuth Dynamic Registration
  - Software Statements for OAuth Dynamic Registration

I think that they all have their place in the world, and this is how I 
see them fitting together:

OAuth Dynamic Registration

What it is: Essentially the draft we have today, draft 14. This draft 
defines a standalone RESTful API for dealing with client registrations, 
it allows for open registration as well as protected registration, and 
perhaps most importantly we know that it works because people have 
implemented it as part of several different APIs. This could have an 
informational pointer to the SCIM draft and the Software Statements 
draft. We could call this one "core" or "basic" or some other modifier, 
but I don't think that's necessary because it already does what it says 
on the tin.

What it needs to concentrate on: This needs to be a "base" document with 
extension hooks in key places (such as the client metadata, which is 
already extensible, and places that have been made extensible like the 
token_endpoint_auth_method, and perhaps others). It needs to get its job 
done, allowing for full specification of the simple case in an 
interoperable way (anonymous registration of self-asserted client 
metadata to receive a client identifier and manage the registration) and 
be extensible and flexible enough for the more complex cases.

What we should do: I think that we should continue shepherding this 
document through WGLC in the OAuth WG because there are no specific open 
issues in the spec (that I, the editor, am aware of) and I've seen what 
I would personally consider to be rough consensus on it (not unanimous, 
but that's not necessary anyway).

SCIM-based OAuth Dynamic Registration:

What it is: Most of Phil's draft, this defines a SCIM profile for 
managing OAuth clients dynamically. This will accomplish the same kinds 
of things that the OAuth Dynamic Registration Draft will accomplish, but 
in a SCIM-like manner. This will have a normative dependency on SCIM (of 
some version), and probably an informational dependency on OAuth Dynamic 
Registration. This could have an informational pointer to the Software 
Statements draft. This draft is very useful if you're already deploying 
a SCIM based system, and if you're investing in SCIM then it's going to 
be a smaller step to support this than it would be the base draft. 
However, I strongly believe that SCIM is a really big jump for 
implementing basic functionality that this is trying to accomplish.

What it needs to concentrate on: Tracking with the overall SCIM 
specification (on which it depends) and tracking with the data model and 
general usage of the OAuth Dynamic Registration protocol (wherever it 
makes sense to do so).

What we should do: I think that this draft should be picked up and 
worked on as an IETF document, but I think that it probably makes more 
sense for that work to be done inside of the SCIM working group. The 
reasons for this are twofold: First, this draft really should look and 
feel like SCIM, and to do that it really needs the attention of the 
group that's defining SCIM. Second, SCIM isn't completed and likely 
won't be for some time to come, and this draft needs to track with that 
protocol as it moves through the IETF process.

Software Statements for OAuth Dynamic Registration

What it is: Section 4 of Phil's draft (plus a few other bits, discussed 
here), this defines a method for presenting signed and/or verifiable 
claims to the registration server's endpoint. This is most useful when 
an authorization server can verify the claims being presented, such as 
being able to discover the signing key from the "iss" claim and validate 
the signature. This could also be used (with some additional 
specification) by a discovery-based system that could fix ahead of time 
some of the claims for a given piece of software (like we've done with 
BlueButton+). In some circumstances, this assertion could even contain 
all relevant bits of the registration, leaving the rest of the metadata 
fields blank. This is essentially the "use the assertion as the 
registration" flow that Phil discussed at the meeting, from what I 
understand. In all of these cases, it can give us a higher assurance for 
the registration and means to tie together multiple instances of a piece 
of software across a network.

What it needs to concentrate on: Making the software statements 
interoperable. I don't think this is going to be an easy task, and I 
think it's going to be a long process to get it *right* for all players.

What we should do: I think that this draft should be picked up by the 
OAuth Working Group as a WG document, and it should be built as an 
extension to both the OAuth Dynamic Registration and SCIM-based OAuth 
Dynamic Registration documents. I think it's important, but it's added 
functionality on top of either the RESTful or the SCIM-based 
registration documents, and as such it should have a normative reference 
to both of them with detailed profiles of how to use them.

So in all, we've got three main documents, each with different purposes 
and concentrations, and with different timelines. I don't see any 
problem with these coexisting, and I think doing things this way can 
cover all of our known use cases and let us actually progress these 
documents and move forward.

  -- Justin

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 6 Aug 2013 23:18:53 +0000

I think that the IETF meeting and session on Dynamic Registration showed how fractured it was and how we don't have consensus on what needs to be done and how it needs to be done. I would not support moving any draft further along in the IETF process. I looked on mailing list and could not find out where any dynamic registration document went to WGLC, so maybe someone can point me to that.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Tuesday, August 6, 2013 2:18 PM
To: [email-masked]
Subject: [OAUTH-WG] A Proposal for Dynamic Registration

At last week's IETF meeting, there was quite a lot of talk about the Dynamic Registration draft as well as a few other related drafts in this space. I would like to propose to the group what I think would be a positive working structure among the different approaches that would let us move everything forward. The source documents in discussion here are the WG's Dynamic Registration (draft 14) and Phil Hunt's individual submission of a SCIM-based alternative with some software assertion components to it. I suggest we refactor these into three documents:

I think that they all have their place in the world, and this is how I see them fitting together:

  -- Justin
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Justin Richer <[email-masked]>
Date: Wed, 7 Aug 2013 10:09:08 -0400

Tony, it happened several months ago:

   http://www.ietf.org/mail-archive/web/oauth/current/msg11326.html

This triggered a lot of discussion and brought up several changes in the 
document, in general for the good. The vast majority of changes were 
editorial in nature, clearing up the intent of the text, but the 
underlying protocol is pretty solid and not very different qualitatively 
from draft -10. At this point, I believe that all open issues are 
addressed in the document or directed towards specific proposed 
extensions, and I haven't heard anything to the contrary.

And I think you're reading the tone content of the discussion 
incorrectly. As I tried to carefully lay out below, I don't see 
fractures. I see multiple components that can work together and fit 
fairly nicely into a larger system. The existence of multiple solutions 
does not invalidate the applicability of a known good solution. We can 
not shelve something good just because there's a hint of something else 
on the horizon (which might be good or bad, we don't know yet).

There is a lot of support for the Dynamic Registration draft that's 
there today, just look at the number of implementers and protocols that 
are actually using it. This is not a theoretical draft, this is not an 
intellectual exercise, this is not a speculative document -- this is a 
codification of real practice that we know works and has been 
implemented and deployed and tested.

And speaking of these other protocols and systems -- they're going to 
move on whether we at the IETF want them to or not. Nobody is going to 
sit around and wait for the IETF-blessed version of this functionality. 
As a matter of fact, this document was born of the output of two groups 
who specifically *didn't* wait around for the IETF to solve this 
problem. We brought it "in house" here because we believed that it would 
be better to have a generally applicable solution than to have a dozen 
proprietary implementations. That's where true fragmentation comes from: 
implementations and deployments, not from minor quibbles about syntax. 
So could we stuff dynamic registration on a shelf and wait for a perfect 
solution to descend from heaven? Sure we could, but that would be so 
profoundly stupid that I would question the sanity of everyone in this 
working group. But if we come up with a solution that works, can be 
implemented, and is done in a timely fashion, then the world *will* use 
it. That's what we have, and that's what I want to move forward.

There's also a lot of support for extensions (software statements) and 
different instantiations (SCIM) of the same basic protocol. These are 
good things, and they speak to the strength of the registration 
protocol, not its weakness.  I believe that what I've laid out below is 
a solid and reasonable plan for moving things forward and addressing 
everything that's been brought up, and so I invite the commentary of the 
whole of the working group. After all, the IETF is an organization of 
individuals and we work on rough consensus and running code.

  -- Justin

---

From: George Fletcher <[email-masked]>
Date: Wed, 07 Aug 2013 10:26:03 -0400

+1

On 8/6/13 5:18 PM, Justin Richer wrote:
> Dynamic Registration draft as well as a few other related drafts in 
> this space. I would like to propose to the group what I think would be 
> a positive working structure among the different approaches that would 
> let us move everything forward. The source documents in discussion 
> here are the WG's Dynamic Registration (draft 14) and Phil Hunt's 
> individual submission of a SCIM-based alternative with some software 
> assertion components to it. I suggest we refactor these into three 
> documents:
>
> defines a standalone RESTful API for dealing with client 
> registrations, it allows for open registration as well as protected 
> registration, and perhaps most importantly we know that it works 
> because people have implemented it as part of several different APIs. 
> This could have an informational pointer to the SCIM draft and the 
> Software Statements draft. We could call this one "core" or "basic" or 
> some other modifier, but I don't think that's necessary because it 
> already does what it says on the tin.
>
> What it needs to concentrate on: This needs to be a "base" document 
> with extension hooks in key places (such as the client metadata, which 
> is already extensible, and places that have been made extensible like 
> the token_endpoint_auth_method, and perhaps others). It needs to get 
> its job done, allowing for full specification of the simple case in an 
> metadata to receive a client identifier and manage the registration) 
> and be extensible and flexible enough for the more complex cases.
>
> document through WGLC in the OAuth WG because there are no specific 
> open issues in the spec (that I, the editor, am aware of) and I've 
> seen what I would personally consider to be rough consensus on it (not 
> unanimous, but that's not necessary anyway).
>
>
>
> managing OAuth clients dynamically. This will accomplish the same 
> kinds of things that the OAuth Dynamic Registration Draft will 
> accomplish, but in a SCIM-like manner. This will have a normative 
> dependency on SCIM (of some version), and probably an informational 
> dependency on OAuth Dynamic Registration. This could have an 
> informational pointer to the Software Statements draft. This draft is 
> very useful if you're already deploying a SCIM based system, and if 
> you're investing in SCIM then it's going to be a smaller step to 
> support this than it would be the base draft. However, I strongly 
> believe that SCIM is a really big jump for implementing basic 
> functionality that this is trying to accomplish.
>
> specification (on which it depends) and tracking with the data model 
> and general usage of the OAuth Dynamic Registration protocol (wherever 
> it makes sense to do so).
>
> won't be for some time to come, and this draft needs to track with 
> that protocol as it moves through the IETF process.
>
>
>
> What it is: Section 4 of Phil's draft (plus a few other bits, 
> discussed here), this defines a method for presenting signed and/or 
> verifiable claims to the registration server's endpoint. This is most 
> useful when an authorization server can verify the claims being 
> presented, such as being able to discover the signing key from the 
> "iss" claim and validate the signature. This could also be used (with 
> some additional specification) by a discovery-based system that could 
> fix ahead of time some of the claims for a given piece of software 
> (like we've done with BlueButton+). In some circumstances, this 
> assertion could even contain all relevant bits of the registration, 
> leaving the rest of the metadata fields blank. This is essentially the 
> "use the assertion as the registration" flow that Phil discussed at 
> the meeting, from what I understand. In all of these cases, it can 
> give us a higher assurance for the registration and means to tie 
> together multiple instances of a piece of software across a network.
>
> registration documents, and as such it should have a normative 
> reference to both of them with detailed profiles of how to use them.
>
>
>
>
>
>
> So in all, we've got three main documents, each with different 
> purposes and concentrations, and with different timelines. I don't see 
> any problem with these coexisting, and I think doing things this way 
> can cover all of our known use cases and let us actually progress 
> these documents and move forward.
>
>  -- Justin

-- 
George Fletcher <http://connect.me/gffletch>

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 7 Aug 2013 14:58:09 +0000

I see plenty of fractures, we discussed many of these at the meeting and several side meetings last week. Specification that are brought to IETF undergo changes, morf into something different all the time regardless of who has implemented the original specifications, OAUTH Core is a fine example of how lots of running code was changed because the specification changed, so because you may have code based upon this is not a reason that it is correct and should not change. I'm not aware of many people using this draft, as in the meeting last week I think we had 2 examples, so more people saying that they have implemented this at scale and the problems it solves would be a good thing. Here are the problems that I see with the current proposal and why we would/could not use it:

1. The schema proposal is not extensible, please look at the issues with SCIM and how the scheme was made extensible in SCIM.
2. This proposal requires that I now provide management at the registration endpoint to manage users and secrets, this is costly. 
3. Yet the development of another endpoint.
4. I don't see any use cases, maybe these should be documented (or point people to these) so we understand what this is actually trying to solve, as this is somewhat of a mystery to me and others.
5. There are a lot of issues that OAUTH does not solve, I don't think that this issue (as I understand it) is in the realm of OAUTH, maybe the applications area would be a better place for this specification

-----Original Message-----
From: Justin Richer [mailto:[email-masked]] 
Sent: Wednesday, August 7, 2013 7:09 AM
To: Anthony Nadalin
Cc: [email-masked]
Subject: Re: [OAUTH-WG] A Proposal for Dynamic Registration

This triggered a lot of discussion and brought up several changes in the document, in general for the good. The vast majority of changes were editorial in nature, clearing up the intent of the text, but the underlying protocol is pretty solid and not very different qualitatively from draft -10. At this point, I believe that all open issues are addressed in the document or directed towards specific proposed extensions, and I haven't heard anything to the contrary.

And I think you're reading the tone content of the discussion incorrectly. As I tried to carefully lay out below, I don't see fractures. I see multiple components that can work together and fit fairly nicely into a larger system. The existence of multiple solutions does not invalidate the applicability of a known good solution. We can not shelve something good just because there's a hint of something else on the horizon (which might be good or bad, we don't know yet).

There is a lot of support for the Dynamic Registration draft that's there today, just look at the number of implementers and protocols that are actually using it. This is not a theoretical draft, this is not an intellectual exercise, this is not a speculative document -- this is a codification of real practice that we know works and has been implemented and deployed and tested.

And speaking of these other protocols and systems -- they're going to move on whether we at the IETF want them to or not. Nobody is going to sit around and wait for the IETF-blessed version of this functionality. 
As a matter of fact, this document was born of the output of two groups who specifically *didn't* wait around for the IETF to solve this problem. We brought it "in house" here because we believed that it would be better to have a generally applicable solution than to have a dozen proprietary implementations. That's where true fragmentation comes from: 
implementations and deployments, not from minor quibbles about syntax. 
So could we stuff dynamic registration on a shelf and wait for a perfect solution to descend from heaven? Sure we could, but that would be so profoundly stupid that I would question the sanity of everyone in this working group. But if we come up with a solution that works, can be implemented, and is done in a timely fashion, then the world *will* use it. That's what we have, and that's what I want to move forward.

There's also a lot of support for extensions (software statements) and different instantiations (SCIM) of the same basic protocol. These are good things, and they speak to the strength of the registration protocol, not its weakness.  I believe that what I've laid out below is a solid and reasonable plan for moving things forward and addressing everything that's been brought up, and so I invite the commentary of the whole of the working group. After all, the IETF is an organization of individuals and we work on rough consensus and running code.

  -- Justin

On 08/06/2013 07:18 PM, Anthony Nadalin wrote:
> you're investing in SCIM then it's going to be a smaller step to support this than it would be the base draft.
> some additional
> specification) by a discovery-based system that could fix ahead of 
> time some of the claims for a given piece of software (like we've done 
> with
> all relevant bits of the registration, leaving the rest of the 
> metadata fields blank. This is essentially the "use the assertion as 
> the registration" flow that Phil discussed at the meeting, from what I 
> understand. In all of these cases, it can give us a higher assurance 
> for the registration and means to tie together multiple instances of a 
> piece of software across a network.
>

---

From: Justin Richer <[email-masked]>
Date: Wed, 7 Aug 2013 11:18:36 -0400

Addressing your points inline:

On 08/07/2013 10:58 AM, Anthony Nadalin wrote:
> I see plenty of fractures, we discussed many of these at the meeting and several side meetings last week. Specification that are brought to IETF undergo changes, morf into something different all the time regardless of who has implemented the original specifications, OAUTH Core is a fine example of how lots of running code was changed because the specification changed, so because you may have code based upon this is not a reason that it is correct and should not change.
And all that has happened with this draft as well. Things have changed 
quite a bit from the original specs, breaking changes that caused huge 
ripples through existing implementations. Eventually though you need to 
say "it's good enough" -- if you keep changing things and don't declare 
something done, people will just get bored and move on. I'm glad that 
you mention OAuth core because it is a great example of our previous 
failure at this -- we took so long to get it out there that there are 
several major non-compliant implementations on the web today, most 
notably Facebook, who have no incentive to change to the final draft 
just because the IETF says so. Let's not screw this up again.

>   I'm not aware of many people using this draft, as in the meeting last week I think we had 2 examples, so more people saying that they have implemented this at scale and the problems it solves would be a good thing.
I agree that more people implementing it would be a good thing, but 
you're ignoring the people that already are. There are also a number of 
people that I've spoken to who are hesitant to implement until things 
are deemed fairly "stable", if not final. Those people will come up with 
their own, mutually-incompatible versions.

> Here are the problems that I see with the current proposal and why we would/could not use it:
>
Yes, it is extensible, I really don't know where you're getting that. 
It's JSON, schema-by-fiat. If you want an extension parameter, just add 
it. Your server has to deal with (as in, not crash if it sees) anything 
in the base spec, and it it has to ignore anything that it doesn't 
understand. Best thing I could think to add here would be an IANA 
registry for the client metadata names -- I personally find such things 
overkill but if the WG wants to go that route, we certainly can.
> 2. This proposal requires that I now provide management at the registration endpoint to manage users and secrets, this is costly.
What users are you talking about here? There aren't any users here that 
I know of. As for secrets, you already have to manage client secrets.

> 3. Yet the development of another endpoint.
Adding an endpoint for specific functionality is a good thing, it lets 
you separate out concerns. You talk like URLs are expensive, which is 
ludicrous. Would you propose we try to cram everything through a single 
URL like SOAP? Let's learn from the mistakes of the past instead of 
repeating them.

> 4. I don't see any use cases, maybe these should be documented (or point people to these) so we understand what this is actually trying to solve, as this is somewhat of a mystery to me and others.
Read appendix B. That's why it's there. If there are more cases that we 
can add, suggest text.
> 5. There are a lot of issues that OAUTH does not solve, I don't think that this issue (as I understand it) is in the realm of OAUTH, maybe the applications area would be a better place for this spe…
This was a chartered item for the group to solve (check the charter for 
yourself), we discussed it several times over the last few years before 
it was made a chartered item (check the archives for yourself), and 
there are people willing to work on the document. That's all it takes 
for this to be in scope in the IETF. Trying to boot it into another 
working group at this stage is just odd to me.

  -- Justin

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 7 Aug 2013 21:59:34 +0000

This proposal provisions and de-provisions clients and allows a client to read/update provisioning data (and it also has to deal with schema extensibility, internationalization among the other things), very similar to SCIM, why do we want different ways to do this ? We also have the JIT proposals in SCIM which make even more sense for quick provisioning clients with limited data. This is a lot of repeat of SCIM.

Schema extensibility is not just the ability to add or replace but the flexibility to model desired objects and relationships that are in the target store schema. We would certainly not want to create yet another store/directory just to register clients.

-----Original Message-----
From: Justin Richer [mailto:[email-masked]] 
Sent: Wednesday, August 7, 2013 8:19 AM
To: Anthony Nadalin
Cc: [email-masked]
Subject: Re: [OAUTH-WG] A Proposal for Dynamic Registration

> I see plenty of fractures, we discussed many of these at the meeting and several side meetings last week. Specification that are brought to IETF undergo changes, morf into something different all t…
And all that has happened with this draft as well. Things have changed quite a bit from the original specs, breaking changes that caused huge ripples through existing implementations. Eventually though you need to say "it's good enough" -- if you keep changing things and don't declare something done, people will just get bored and move on. I'm glad that you mention OAuth core because it is a great example of our previous failure at this -- we took so long to get it out there that there are several major non-compliant implementations on the web today, most notably Facebook, who have no incentive to change to the final draft just because the IETF says so. Let's not screw this up again.

>   I'm not aware of many people using this draft, as in the meeting last week I think we had 2 examples, so more people saying that they have implemented this at scale and the problems it solves wou…
I agree that more people implementing it would be a good thing, but you're ignoring the people that already are. There are also a number of people that I've spoken to who are hesitant to implement until things are deemed fairly "stable", if not final. Those people will come up with their own, mutually-incompatible versions.

Yes, it is extensible, I really don't know where you're getting that. 
It's JSON, schema-by-fiat. If you want an extension parameter, just add it. Your server has to deal with (as in, not crash if it sees) anything in the base spec, and it it has to ignore anything that it doesn't understand. Best thing I could think to add here would be an IANA registry for the client metadata names -- I personally find such things overkill but if the WG wants to go that route, we certainly can.
> 2. This proposal requires that I now provide management at the registration endpoint to manage users and secrets, this is costly.
What users are you talking about here? There aren't any users here that I know of. As for secrets, you already have to manage client secrets.

> 3. Yet the development of another endpoint.
Adding an endpoint for specific functionality is a good thing, it lets you separate out concerns. You talk like URLs are expensive, which is ludicrous. Would you propose we try to cram everything through a single URL like SOAP? Let's learn from the mistakes of the past instead of repeating them.

> 4. I don't see any use cases, maybe these should be documented (or point people to these) so we understand what this is actually trying to solve, as this is somewhat of a mystery to me and others.
Read appendix B. That's why it's there. If there are more cases that we can add, suggest text.
> 5. There are a lot of issues that OAUTH does not solve, I don't think 
> that this issue (as I understand it) is in the realm of OAUTH, maybe 
> the applications area would be a better place for this specification
This was a chartered item for the group to solve (check the charter for yourself), we discussed it several times over the last few years before it was made a chartered item (check the archives for yourself), and there are people willing to work on the document. That's all it takes for this to be in scope in the IETF. Trying to boot it into another working group at this stage is just odd to me.r

  -- Justin
>> Software Statements draft. We could call this one "core" or "basic" 
>> or some other modifier, but I don't think that's necessary because it 
>> with extension hooks in key places (such as the client metadata, 
>> which is already extensible, and places that have been made 
>> extensible like the token_endpoint_auth_method, and perhaps others). 
>> It needs to get its job done, allowing for full specification of the 
>> simple case in an interoperable way (anonymous registration of 
>> self-asserted client metadata to receive a client identifier and 
>> manage the registration) and be extensible and flexible enough for the more complex cases.
>>
>> seen what I would personally consider to be rough consensus on it 
>> (not unanimous, but that's not necessary anyway).
>>
>>
>>
>> and general usage of the OAuth Dynamic Registration protocol 
>> (wherever it makes sense to do so).
>>
>> worked on as an IETF document, but I think that it probably makes 
>> more sense for that work to be done inside of the SCIM working group. 
>> The reasons for this are twofold: First, this draft really should 
>> look and feel like SCIM, and to do that it really needs the attention 
>> of the group that's defining SCIM. Second, SCIM isn't completed and 
>> likely won't be for some time to come, and this draft needs to track 
>> with that protocol as it moves through the IETF process.
>>
>>
>>
>> time some of the claims for a given piece of software (like we've 
>> done with
>> BlueButton+). In some circumstances, this assertion could even 
>> BlueButton+contain
>> the registration" flow that Phil discussed at the meeting, from what 
>> I understand. In all of these cases, it can give us a higher 
>> assurance for the registration and means to tie together multiple 
>> instances of a piece of software across a network.
>>
>> Dynamic Registration documents. I think it's important, but it's 
>> added functionality on top of either the RESTful or the SCIM-based 
>> purposes and concentrations, and with different timelines. I don't 
>> see any problem with these coexisting, and I think doing things this 
>> way can cover all of our known use cases and let us actually progress

---

From: Justin Richer <[email-masked]>
Date: Thu, 8 Aug 2013 09:50:25 -0400

You could make that argument about any RESTful patterned API. While SCIM 
is making great progress and is a very good protocol, and I think it's a 
gross mistake to hit every REST-shaped nail with a SCIM-shaped hammer. 
It might make a lot of sense to you if you've already got an investment 
in a SCIM architecture, but not everyone who's doing OAuth-protected 
APIs is doing SCIM. As a matter of fact, the overwhelmingly vast 
majority of protected APIs aren't SCIM, and adopting all of the 
trappings of SCIM for just this one use case doesn't make sense for all 
of these folks.

However, for those who already have SCIM and want to do something SCIM 
based for OAuth client provisioning, I think that's fine for them, and 
that's why I suggest that the SCIM based proposal go forward as well 
(and probably in the SCIM working group). But the existence of a 
SCIM-based method of doing this doesn't invalidate the RESTful protocol 
any more than the existence of several proprietary or otherwise 
protocol-specific means of doing this are. It's the same way that 
someone with a SCIM endpoint who wants to do OpenID Connect will 
probably use their SCIM endpoints instead of the UserInfo Endpoint. So 
you want something SCIM based? Go build it. I'm not stopping you, and in 
fact, I'm encouraging you to do so. I'll review and help edit the crap 
out of that spec, too.

In spite of what you're arguing, the Dyn Reg spec doesn't have to die in 
order for the SCIM spec to move forward. Maybe in five years time, 
everyone will implement that standard and not this one, or maybe it'll 
be the other way around, or maybe we'll all be off of OAuth by then on 
to the next shiny thing. But that's all pointless conjecture when we've 
got one proposed standard that's basically done and that people are 
using, one proposed standard with a clear path forward (as it's parent 
standard isn't done yet, it has some time to go), and one proposed 
extension to both of them that has a lot of potential but needs a lot of 
work. So let's do that.

And I think there's a point that a lot of people are missing here: 
standards are only worth something if people actually implement them. 
People are already implementing the spec that we have, and will continue 
to do so even if the IETF drops it. Doesn't it make more sense to codify 
this practice instead of pretending the world will march to what we say 
in our little working group? I'd like to remind the group that this is 
how this spec started and where it came from: several groups were 
already building mutually incompatible registration specifications. We 
decided to talk with all of these groups and try and make a common 
protocol that everyone could use and extend. I know of at least four 
protocol-specific specs that (over time) went into the dyn reg we have 
now, and there are others out there as well I'm sure.

  -- Justin

---

From: Josh Mandel <[email-masked]>
Date: Thu, 8 Aug 2013 07:51:00 -0700

> not everyone who's doing OAuth-protected APIs is doing SCIM

+1.  (I'd wager very few have even heard of it.)

> to do so even if the IETF drops it.

+1.

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 8 Aug 2013 15:43:27 +0000

There are implantation of SCIM out there in production in large and small scale companies provisioning a heck of a lot of clients, so fully understand all your points about implementations, and thus my concerns about what is being proposed with the dyn reg, who would use it, do we already have something that is close enough, is it solving the right issues, can it be made better more flexible to include other extensible mechanisms, does it include things that are beyond the scope (like client configuration endpoint)etc.  I don't think this spec is anywhere near WGLC, thus all the activity on the list, in the meetings and interim calls, fixing the specification and answering the concerns may help drive more adoption and usage. 

I'm not sure 2 or more specifications solving the same or close issues will really help IETF and the various participants, as this just adds to confusion and potential interoperability issues.

-----Original Message-----
From: Justin Richer [mailto:[email-masked]] 
Sent: Thursday, August 8, 2013 6:50 AM
To: Anthony Nadalin
Cc: [email-masked]
Subject: Re: [OAUTH-WG] A Proposal for Dynamic Registration

You could make that argument about any RESTful patterned API. While SCIM is making great progress and is a very good protocol, and I think it's a gross mistake to hit every REST-shaped nail with a SCIM-shaped hammer. 
It might make a lot of sense to you if you've already got an investment in a SCIM architecture, but not everyone who's doing OAuth-protected APIs is doing SCIM. As a matter of fact, the overwhelmingly vast majority of protected APIs aren't SCIM, and adopting all of the trappings of SCIM for just this one use case doesn't make sense for all of these folks.

However, for those who already have SCIM and want to do something SCIM based for OAuth client provisioning, I think that's fine for them, and that's why I suggest that the SCIM based proposal go forward as well (and probably in the SCIM working group). But the existence of a SCIM-based method of doing this doesn't invalidate the RESTful protocol any more than the existence of several proprietary or otherwise protocol-specific means of doing this are. It's the same way that someone with a SCIM endpoint who wants to do OpenID Connect will probably use their SCIM endpoints instead of the UserInfo Endpoint. So you want something SCIM based? Go build it. I'm not stopping you, and in fact, I'm encouraging you to do so. I'll review and help edit the crap out of that spec, too.

In spite of what you're arguing, the Dyn Reg spec doesn't have to die in order for the SCIM spec to move forward. Maybe in five years time, everyone will implement that standard and not this one, or maybe it'll be the other way around, or maybe we'll all be off of OAuth by then on to the next shiny thing. But that's all pointless conjecture when we've got one proposed standard that's basically done and that people are using, one proposed standard with a clear path forward (as it's parent standard isn't done yet, it has some time to go), and one proposed extension to both of them that has a lot of potential but needs a lot of work. So let's do that.

And I think there's a point that a lot of people are missing here: 
standards are only worth something if people actually implement them. 
People are already implementing the spec that we have, and will continue to do so even if the IETF drops it. Doesn't it make more sense to codify this practice instead of pretending the world will march to what we say in our little working group? I'd like to remind the group that this is how this spec started and where it came from: several groups were already building mutually incompatible registration specifications. We decided to talk with all of these groups and try and make a common protocol that everyone could use and extend. I know of at least four protocol-specific specs that (over time) went into the dyn reg we have now, and there are others out there as well I'm sure.

  -- Justin

On 08/07/2013 05:59 PM, Anthony Nadalin wrote:
> This was a chartered item for the group to solve (check the charter 
> for yourself), we discussed it several times over the last few years 
> before it was made a chartered item (check the archives for yourself), 
> and there are people willing to work on the document. That's all it 
> takes for this to be in scope in the IETF. Trying to boot it into 
> another working group at this stage is just odd to me.r
>
>    -- Justin
>>
>>
>>> What it is: Essentially the draft we have today, draft 14. This 
>>> draft defines a standalone RESTful API for dealing with client 
>>> or some other modifier, but I don't think that's necessary because 
>>> it already does what it says on the tin.
>>>
>>> informational pointer to the Software Statements draft. This draft 
>>> is very useful if you're already deploying a SCIM based system, and 
>>> if you're investing in SCIM then it's going to be a smaller step to support this than it would be the base draft.
>>> look and feel like SCIM, and to do that it really needs the 
>>> attention of the group that's defining SCIM. Second, SCIM isn't 
>>> completed and likely won't be for some time to come, and this draft 
>>> needs to track with that protocol as it moves through the IETF process.
>>>
>>>
>>>
>>> verifiable claims to the registration server's endpoint. This is 
>>> most useful when an authorization server can verify the claims being 
>>> "iss" claim and validate the signature. This could also be used 
>>> (with some additional
>>> What we should do: I think that this draft should be picked up by 
>>> the OAuth Working Group as a WG document, and it should be built as 
>>> an extension to both the OAuth Dynamic Registration and SCIM-based 
>>> OAuth Dynamic Registration documents. I think it's important, but 
>>> it's added functionality on top of either the RESTful or the 
>>> SCIM-based registration documents, and as such it should have a 
>>> normative reference to both of them with detailed profiles of how to use them.
>>>
>>>
>>>
>>>
>>>
>>>
>>> way can cover all of our known use cases and let us actually 
>>> progress these documents and move forward.
>>>
>>>      -- Justin

---

From: Phil Hunt <[email-masked]>
Date: Sun, 11 Aug 2013 16:27:49 -0700

+1 

I also would like to explore the assertion exchange concept that doesn't require any endpoint. 

I see no point in rushing here. 

More than one method makes no sense unless there is a fundamental reason. We have none. 

Dyn reg duplicates scim and we have to reconcile this now or with the iesg. 

Phil

---

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 12 Aug 2013 00:59:23 +0000

I think it's more proper to say that SCIM duplicates every RESTful API, ever. 

 -- Justin
________________________________________
From: Phil Hunt [[email-masked]]
Sent: Sunday, August 11, 2013 7:27 PM
To: Anthony Nadalin
Cc: Richer, Justin P.; [email-masked]
Subject: Re: [OAUTH-WG] A Proposal for Dynamic Registration

+1

Phil

---

From: Leif Johansson <[email-masked]>
Date: Mon, 12 Aug 2013 11:34:18 +0200

On 08/06/2013 11:18 PM, Justin Richer wrote:

<snip>
>  - Software Statements for OAuth Dynamic Registration

This thread makes me think we should break out the EXPERIMENTAL
track: spin two or more proposed solutions as EXPERIMENTAL. Let the
various groups do what they're gona do (which they'll do anyway) and
the the chips fall where they may.

Tony is right in interpreting the discussions in Berlin as quite fractured.
Pushing for standards track seems premature.

OTOH the transition from EXPERIMENTAL to STANDARDS TRACK can
be as quick as a couple of I-Ds describing the outcome of the
implementation and deployment work that will happen anyway (as
you so correctly observe) after which the WG decides how to move
forward.

Since bb+ and openidc will do dynreg anyway the document track
doesn't really matter which means the usual "vendors won't implement
unless its a real RFC"-argument doesn't apply here anyway.

        Cheers Leif

---

From: Prateek Mishra <[email-masked]>
Date: Mon, 12 Aug 2013 09:02:20 -0400

+1

I dont see a consensus within the community in this area.

My own sense is that people are exploring many different approaches to 
the problem; there seem to be wide-variety of use-cases involved.

- prateek

---

From: Justin Richer <[email-masked]>
Date: Mon, 12 Aug 2013 10:09:04 -0400

I think it's very important that we put *some* stake in the ground for 
the likes of OIDC, BB+, UMA, and the other higher-level protocols and 
systems that are looking toward us for Dyn Reg now. They weren't, 
previously -- all of these had mutually incompatible registration 
systems, but the work we've done so far with Dyn Reg has made a system 
that everyone can use. If we don't declare a baseline, and do so soon, 
then I fully believe that these groups will either fracture 
unnecessarily, or they'll ignore the IETF. Or both. I'll leave it to the 
chairs to decide if this gets tagged "experimental" or "standards", but 
I think that we're doing the world a disservice by not shipping what we 
have.

  -- Justin

---

From: Phil Hunt <[email-masked]>
Date: Mon, 12 Aug 2013 20:43:17 +0200

Inline…

Phil

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

On 2013-08-12, at 4:09 PM, Justin Richer <[email-masked]> wrote:

> I think it's very important that we put *some* stake in the ground for the likes of OIDC, BB+, UMA, and the other higher-level protocols and systems that are looking toward us for Dyn Reg now. They weren't, previously -- all of these had mutually incompatible registration systems, but the work we've done so far with Dyn Reg has made a system that everyone can use. If we don't declare a baseline, and do so soon, then I fully believe that these groups will either fracture unnecessarily, or they'll ignore the IETF. Or both.

[PH] Your position here indicates to me that there is not a lot of natural consensus between OIDC, BB+, UMA and others. If these groups are aligning solely because of moral pressure to have a single standard -- which you seem to imply by the need to "put a stake in the ground", it suggests the technical proposal is not right yet.

Despite your disparaging of SCIM, I don't think that's the issue.  Whether SCIM or custom API, the Dyn Reg model places too much complexity solely on the client to registration endpoint relationship.

For example, the information content of what the client is asserting is *not* dynamic - only the act of registration is. The client app is for the most part, "fixed", coded in a particular way for use with a specific set of APIs. Dyn Reg (and the SCIM variant) go well beyond just issuing a client_id and exchange all oauth protocol information on the assumption any value might change.  This is a very complex approach.

Then there is the issue of needing full CRUD support, I have not bought into the need for apps to be able to update registration.  Why would they do this?  We do we need de-registration, wouldn't Torsten's revocation draft suffice?

The reason I think the assertion model might be a better path, is that it assumes a larger multi-party flow which moves complexity away from the registration endpoint to the point that in most cases a simple cert swap is all that is needed from the clients perspective.

When Tony and I put forward the SCIM variant, we thought that might be a compromise.  Still after putting it forward, I now feel the same way about it as I do the Dyn Reg draft.  What is useful from it, is the notion of defining a software statement which can be used to simplify the registration process greatly.

> I'll leave it to the chairs to decide if this gets tagged "experimental" or "standards", but I think that we're doing the world a disservice by not shipping what we have.
> 
> -- Justin
>

---

From: Justin Richer <[email-masked]>
Date: Mon, 12 Aug 2013 15:30:58 -0400

I think you're misunderstanding what I'm saying with regard to the 
various protocols -- the different registration systems weren't 
incompatible for any deep seated assumptions or different data models. 
They were incompatible because of different names, different formats, 
different things being used to do the same thing. Small, stupid 
differences that none of the groups were particularly tied to at the 
time, but getting them all to agree to call something "foo" and not 
"bar" is where the draft that we have came in. Now you're suggesting 
that we go back to all these groups and say "well we know we told you to 
use 'foo' for this field, but now instead we're going to change it to 
'bar', except that 'bar' isn't exactly 'bar', it's more like 'baz', and 
you need to throw out half your use cases". Ridiculous, is it not?

All of your questions about what's required or not for supporting 
dynamic client registration have been brought up and discussed in the 
history of the document in its various forms over the past couple years. 
It started out as a one-way registration, no CRUD ops or lifecycle 
management. Then people started to use it and realized that we needed 
those things, so we've added them. Once we were in that direction, we 
realized we were doing CRUD-like operations but weren't being RESTful 
where it made sense to be, so now it's a JSON-based RESTful API. We used 
to force client secrets to be used (even by public clients using things 
like the implicit or assertion flows) to access this API, but then we 
realized we could eat our own dogfood and use OAuth tokens, and that's 
where we got the registration access token. We used to have registration 
be an open POST only, but then there were very real use cases, real 
deployments, and real extension mechanisms that could be enabled by 
having the initial registration optionally be protected as an OAuth2 
protected resource as well, so that's where we got the initial access 
token. We originally had a fixed set of client parameters, but groups 
quickly wanted to add more, so we made that extensible. We originally 
had simple string values, but people wanted to be able to have localized 
text as well, so that was added.

All of these are visible in the document history, particularly if you 
look at it across the IETF, UMA, and OpenID specs as a whole. You make 
it sound as if we simply waved our hands and grabbed a bunch of features 
out of thin air and implemented them, and that's absolutely not the 
case. Everything in that draft is the result of lots of discussion, 
implementation, and deployment. Do I need to mention again that people 
are actively running this code today?

Also, I don't intend to disparage the SCIM protocol -- it's a great 
protocol for what it does, and in user and group provisioning it's 
exactly what I look toward. We're looking to potentially deploy it on 
some of my projects as well, so I'm certainly not against it. However, 
I'm not one to see it as a silver bullet for solving all RESTful API 
problems in the world, and that's exactly what I see it being positioned 
as here. Every function in the Dyn Reg spec that you claim "duplicates" 
SCIM are actually just things that it gets from being RESTful. So in 
other words, the similarities are from similar genetics, not from direct 
competition. Quite frankly, I think that what's happening here is that 
by taking the SCIM-hammer in hand you're seeing OAuth Dyn Reg as a nail. 
Also, I still think that you're ignoring the cost of implementing SCIM 
for people who aren't already doing so, especially when compared to the 
cost of implementing another (smaller, simpler, fit-to-purpose) RESTful API.

As to the direct assertions, I'm interested in seeing where it goes, but 
I don't yet (today) see how it can work in practice. And in any case it 
needs a lot more work. Take the code flow, for example -- how does the 
client present the assertion to the authorization endpoint? And what 
does it use for client_id (a required parameter)? Also, to the question 
that I asked at the IETF meeting, what about the case where you've got 
hundreds of thousands of auth servers protecting the same kind of API -- 
where does a client go to get its assertion then?

As to the "dynamic" nature of the clients, it's the *relationship* 
that's dynamic. You're once again conflating the code that executes with 
the instance of the code as seen by a particular authorization server. 
Also, in my own personal experience, there are things that change for a 
given piece of code depending on its deployment circumstances -- the 
redirect_uris for a web client, for instance, are going to be different 
depending on *where* that client software is served from.

Judging by our past conversations, I think that your model of what makes 
up a client and what makes up an auth server is valid, but limited, and 
this is continuing to color your view of what this protocol needs. I'd 
rather have something that works across the many ways that OAuth is 
being used today and can be used in the future.

  -- Justin

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 13 Aug 2013 10:44:57 +0300

For whatever it is worth, let me add my 2c, I've briefly looked through 
the latest Dynamic Registration Draft, and also briefly looked at SCIM - 
interesting specification, did not know it even exists :-).

IMHO these are 2 rather different texts, SCIM looks very useful, look 
forward to understanding it better :-), but it appears to be at a higher 
level than Dyn Reg Draft is - the latter is centric around a specific 
use case as far as I can see and the whole language of the latter is 
about addressing this specific use case. Appears to me SCIM and DynReq 
of OAuth2 Clients texts complement each other as opposed to 'compete' 
with each other, and they intersect simply because they use some similar 
terminology. I may be repeating some of what is said below.

Re the use of assertions: I'd like to think that getting the assertions 
flowing in OAuth2 applications is useful only when we have a task of 
integrating with existing IDPs or some other involved scenarios. Using 
them as the central pieces of the protocol will raise the complexity bar.

Apologies for not commenting inline - the above is just the comments 
after a brief overview of the documents :-)

Cheers, Sergey

On 12/08/13 22:30, Justin Richer wrote:
>>> I think it's very important that we put *some* stake in the ground
>>> for the likes of OIDC, BB+, UMA, and the other higher-level protocols
>>> and systems that are looking toward us for Dyn Reg now. They weren't,
>>> systems, but the work we've done so far with Dyn Reg has made a
>>> system that everyone can use. If we don't declare a baseline, and do
>>> so soon, then I fully believe that these groups will either fracture
>>> unnecessarily, or they'll ignore the IETF. Or both.
>> [PH] Your position here indicates to me that there is not a lot of
>> natural consensus between OIDC, BB+, UMA and others. If these groups
>> are aligning solely because of moral pressure to have a single
>> standard -- which you seem to imply by the need to "put a stake in the
>> ground", it suggests the technical proposal is not right yet.
>>
>> Despite your disparaging of SCIM, I don't think that's the issue.
>> Whether SCIM or custom API, the Dyn Reg model places too much
>> complexity solely on the client to registration endpoint relationship.
>>
>> For example, the information content of what the client is asserting
>> is *not* dynamic - only the act of registration is. The client app is
>> for the most part, "fixed", coded in a particular way for use with a
>> specific set of APIs. Dyn Reg (and the SCIM variant) go well beyond
>> just issuing a client_id and exchange all oauth protocol information
>> on the assumption any value might change.  This is a very complex
>> approach.
>>
>> Then there is the issue of needing full CRUD support, I have not
>> bought into the need for apps to be able to update registration.  Why
>> would they do this?  We do we need de-registration, wouldn't Torsten's
>> revocation draft suffice?
>>
>> The reason I think the assertion model might be a better path, is that
>> it assumes a larger multi-party flow which moves complexity away from
>> the registration endpoint to the point that in most cases a simple
>> cert swap is all that is needed from the clients perspective.
>>
>> When Tony and I put forward the SCIM variant, we thought that might be
>> a compromise.  Still after putting it forward, I now feel the same way
>> about it as I do the Dyn Reg draft.  What is useful from it, is the
>> notion of defining a software statement which can be used to simplify
>> the registration process greatly.
>>
>>> I'll leave it to the chairs to decide if this gets tagged
>>> "experimental" or "standards", but I think that we're doing the world
>>> a disservice by not shipping what we have.
>>>
>>> -- Justin
>>>

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 13 Aug 2013 14:38:59 +0000

so the CRUD operations are not an overlap, the provisioning aspects are not an overlap, Interesting view

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sergey Beryozkin
Sent: Tuesday, August 13, 2013 12:45 AM
To: [email-masked]
Subject: Re: [OAUTH-WG] A Proposal for Dynamic Registration

For whatever it is worth, let me add my 2c, I've briefly looked through the latest Dynamic Registration Draft, and also briefly looked at SCIM - interesting specification, did not know it even exists :-).

IMHO these are 2 rather different texts, SCIM looks very useful, look forward to understanding it better :-), but it appears to be at a higher level than Dyn Reg Draft is - the latter is centric around a specific use case as far as I can see and the whole language of the latter is about addressing this specific use case. Appears to me SCIM and DynReq of OAuth2 Clients texts complement each other as opposed to 'compete' 
with each other, and they intersect simply because they use some similar terminology. I may be repeating some of what is said below.

Re the use of assertions: I'd like to think that getting the assertions flowing in OAuth2 applications is useful only when we have a task of integrating with existing IDPs or some other involved scenarios. Using them as the central pieces of the protocol will raise the complexity bar.

Apologies for not commenting inline - the above is just the comments after a brief overview of the documents :-)

Cheers, Sergey

On 12/08/13 22:30, Justin Richer wrote:
> that we go back to all these groups and say "well we know we told you 
> to use 'foo' for this field, but now instead we're going to change it 
> to 'bar', except that 'bar' isn't exactly 'bar', it's more like 'baz', 
> and you need to throw out half your use cases". Ridiculous, is it not?
>
> where it made sense to be, so now it's a JSON-based RESTful API. We 
> used to force client secrets to be used (even by public clients using 
> things like the implicit or assertion flows) to access this API, but 
> then we realized we could eat our own dogfood and use OAuth tokens, 
> and that's where we got the registration access token. We used to have 
> registration be an open POST only, but then there were very real use 
> cases, real deployments, and real extension mechanisms that could be 
> enabled by having the initial registration optionally be protected as 
> an OAuth2 protected resource as well, so that's where we got the 
> initial access token. We originally had a fixed set of client 
> parameters, but groups quickly wanted to add more, so we made that 
> extensible. We originally had simple string values, but people wanted 
> to be able to have localized text as well, so that was added.
>
> it sound as if we simply waved our hands and grabbed a bunch of 
> features out of thin air and implemented them, and that's absolutely 
> not the case. Everything in that draft is the result of lots of 
> discussion, implementation, and deployment. Do I need to mention again 
> that people are actively running this code today?
>
> problems in the world, and that's exactly what I see it being 
> positioned as here. Every function in the Dyn Reg spec that you claim "duplicates"
> other words, the similarities are from similar genetics, not from 
> direct competition. Quite frankly, I think that what's happening here 
> is that by taking the SCIM-hammer in hand you're seeing OAuth Dyn Reg as a nail.
> for people who aren't already doing so, especially when compared to 
> the cost of implementing another (smaller, simpler, fit-to-purpose) 
> RESTful API.
>
> As to the direct assertions, I'm interested in seeing where it goes, 
> but I don't yet (today) see how it can work in practice. And in any 
> case it needs a lot more work. Take the code flow, for example -- how 
> does the client present the assertion to the authorization endpoint? 
> And what does it use for client_id (a required parameter)? Also, to 
> the question that I asked at the IETF meeting, what about the case 
> where you've got hundreds of thousands of auth servers protecting the 
> same kind of API -- where does a client go to get its assertion then?
>
> that's dynamic. You're once again conflating the code that executes 
> with the instance of the code as seen by a particular authorization server.
> Also, in my own personal experience, there are things that change for 
> a given piece of code depending on its deployment circumstances -- the 
> redirect_uris for a web client, for instance, are going to be 
> different depending on *where* that client software is served from.
>
> Judging by our past conversations, I think that your model of what 
> makes up a client and what makes up an auth server is valid, but 
> limited, and this is continuing to color your view of what this 
> protocol needs. I'd rather have something that works across the many 
> ways that OAuth is being used today and can be used in the future.
>
>   -- Justin
>
>> Inline...
>>> for the likes of OIDC, BB+, UMA, and the other higher-level 
>>> protocols and systems that are looking toward us for Dyn Reg now. 
>>> They weren't, previously -- all of these had mutually incompatible 
>>> registration systems, but the work we've done so far with Dyn Reg 
>>> has made a system that everyone can use. If we don't declare a 
>>> baseline, and do so soon, then I fully believe that these groups 
>>> will either fracture unnecessarily, or they'll ignore the IETF. Or both.
>> standard -- which you seem to imply by the need to "put a stake in 
>> the ground", it suggests the technical proposal is not right yet.
>>
>> would they do this?  We do we need de-registration, wouldn't 
>> Torsten's revocation draft suffice?
>>
>> The reason I think the assertion model might be a better path, is 
>> that it assumes a larger multi-party flow which moves complexity away 
>> from the registration endpoint to the point that in most cases a 
>> simple cert swap is all that is needed from the clients perspective.
>>
>> When Tony and I put forward the SCIM variant, we thought that might 
>> be a compromise.  Still after putting it forward, I now feel the same 
>> way about it as I do the Dyn Reg draft.  What is useful from it, is 
>> the notion of defining a software statement which can be used to 
>> simplify the registration process greatly.
>>
>>> "experimental" or "standards", but I think that we're doing the 
>>> world a disservice by not shipping what we have.
>>>
>>> -- Justin
>>>
>>>> various groups do what they're gona do (which they'll do anyway) 
>>>> and the the chips fall where they may.
>>>>
>>>> OTOH the transition from EXPERIMENTAL to STANDARDS TRACK can be as 
>>>> quick as a couple of I-Ds describing the outcome of the 
>>>> implementation and deployment work that will happen anyway (as you 
>>>> so correctly observe) after which the WG decides how to move 
>>>> forward.
>>>>
>>>> doesn't really matter which means the usual "vendors won't 
>>>> implement unless its a real RFC"-argument doesn't apply here anyway.
>>>>
>>>>          Cheers Leif
>>>>
>>>>
>>>>

---

From: Justin Richer <[email-masked]>
Date: Tue, 13 Aug 2013 10:46:14 -0400

On 08/13/2013 10:38 AM, Anthony Nadalin wrote:
> so the CRUD operations are not an overlap, the provisioning aspects are not an overlap

Correct.

  -- Justin

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 14 Aug 2013 09:55:19 +0300

Hi Tony,
> so the CRUD operations are not an overlap, the provisioning aspects are not an overlap, Interesting view
The texts are different, that was really my point, yes, both talk CRUD 
and I guess provisioning, but SCIM text appears to be much more generic 
to me

Cheers, Sergey