> -----Original Message----- > From: Richer, Justin P. [mailto:jric...@mitre.org] > Sent: Wednesday, March 14, 2012 7:51 PM
> [...] the AS-PR connection is a real and present known > gap introduced in OAuth2 (since OAuth1 didn't even think of them as > separate entities) and *somebody* should be trying to codify the best ways > to fill that gap and I think this is a good place to do it. I'm not sure this is an issue for more existing implementations given that it is just an internal implementation detail. It becomes more of a use case when you have different entities managing the different roles. I'm not objecting to this line of work, but I we do need a proposal and it should be based on something more than just ideas (e.g. some deployment experience). One of the benefit of starting off a draft and not just ideas is that it shows real interest and traction. > Along those lines, I don't think that SWD really belongs in the OAuth group > either *except* for the fact that there's a Discovery mandate below that > nobody's contesting. It's arguable that this simply covers the WWW- > Authenticate header and its value in different contexts, but we all know this > is incomplete discovery at best. Discovery is a very wide topic. The only discovery item proposed I the dynamic client registration proposal. It is fine to discuss potential discovery tools in this context, but we should not be the primary source of innovation in the space. So we're in agreement that SWD doesn't belong here. Nor does WebFinger which is working on similar problems. The ideal scenario would be to get traction on these general purpose discovery mechanisms elsewhere, and revisit this when the working group is discussing the dynamic client registration proposal. IOW, we may end up discussing and contributing to an APPS area discovery work to ensure our needs are supported, but not publish such documents in the WG. > JWT also doesn't feel like it really belongs > here, but since JOSE won't have it, it's a fairly important orphan that's > already > seeing deployment experience. I don't have strong opinions on this, mostly because I understand it to be fairly finished. If the WG will need to spend a few months discussing it, I will have to reconsider. > Add to all of this that I have two other drafts that I'd like to see dusted > off > and moved forward through some process -- alternate encoding (XML and > Form parameters) from the token endpoint, and the UX/dynreg related > "instance information" draft. I'll have versions of both of these uploaded > once the IETF tracker takes the locks off at the end of the month. I think the XML draft is simple enough to include. I've supported it in the last round. I think the UX work is actually really important if someone is willing to take the lead on that and do the work. > Neither of > these saw much WG feedback or support before, though, so I'm open to > suggestions of what a better home for them might be, if there is one. Or > maybe we should make a new group for all the orphaned open web specs? I think many people here don't fully understand the ways the IETF works. While working groups are the main venue for collaboration, there is a lot of work done on an Individual Submission basis (more than half?). This means a specification is created and finalized outside an official WG and without a charter. The general mechanism (at least as used pretty effectively by me for a handful of published RFCs) is to find the right mailing list (e.g. HTTP for Link relations, Apps Discuss for host-meta and well-known, OAuth for OAuth 1.0) and support from an Area Director. You also need to fine a document shepherd to help review and help with the "paperwork". The way this works is that you can write a specification, discuss it on the WG list, and when you feel it is ready, ask the sponsoring AD for IETF Last Call. The AD might decide this is better suited to go through the full WG process, or feel that the document is simple and narrow enough to skip it. It is also possible that some of this work will be discussed on this list, but sponsored by an APPS area AD (e.g. the XML extension is a perfect example for something that is really not a security protocol component). So you have options. IOW, getting your draft onto the charter is actually not always the best option for a straight-forward but low priority/interest work. The individual submission track might be better for you and the WG. You might want to reach out to one of the ADs or Chairs and discuss these options. EH _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
