Where is this access control and user centric architecture described? I could not find it.
EH On Apr 12, 2012, at 14:01, "John Bradley" <ve7...@ve7jtb.com> wrote: > There are important deployment and privacy issues that caused openID Connect > to use SWD. > > I was part of the OASIS XRI/XRD work that Web Finger has been based on. > > The main differences are around allowing all of the users information to be > publicly discoverable, vs providing for access control. > > They are similar, but have real design differences. > > Web Finger without XML is not horrible by any means, but nether is SWD. > > SWD is more about users while host-meta is more about server resources. > > John B. > > > On 2012-04-12, at 7:33 PM, Igor Faynberg wrote: > >> To me this looks like more than the same problem being solved--it appears to >> be the same protocol... I wonder if, the representation issues were put >> aside (i.e., left to the API specification), the common part is what can be >> adopted. >> >> Igor >> >> On 4/12/2012 8:01 AM, Stephen Farrell wrote: >>> >>> >>> On 04/12/2012 12:00 PM, Hannes Tschofenig wrote: >>>> Hi all, >>>> >>>> those who had attended the last IETF meeting may have noticed the ongoing >>>> activity in the 'Applications Area Working Group' regarding Web Finger. >>>> We had our discussion regarding Simple Web Discovery (SWD) as part of the >>>> re-chartering process. >>>> >>>> Here are the two specifications: >>>> http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03 >>>> http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 >>>> >>>> Now, the questions that seems to be hanging around are >>>> >>>> 1) Aren't these two mechanisms solving pretty much the same problem? >>>> 2) Do we need to have two standards for the same functionality? >>>> 3) Do you guys have a position or comments regarding either one of them? >>>> >>>> Ciao >>>> Hannes >>>> >>>> PS: Please also let me know if your view is: "I don't really know what all >>>> this is about and the documents actually don't provide enough requirements >>>> to make a reasonable judgement about the solution space." >>>> >>> >>> So just as a data-point. We (the IETF, but including >>> me personally;-) mucked up badly on this some years >>> ago in the PKI space - we standardised both CMP (rfc >>> 2510) and CMC (rfc 2797) as two ways to do the same >>> thing, after a protracted battle between factions >>> supporting one or the other. We even made sure they >>> had as much common syntax as possible. (CRMF, rfc >>> 2511) >>> >>> Result: neither fully adopted, lots of people still >>> do proprietary stuff, neither can be killed off >>> (despite attempts), both need to be maintained (CMP >>> is now RFC 4210, CMC, 5272, CRMF, 4211), and IMO >>> partly as a result of us screwing up for what seemed >>> like good reasons at the time, PKI administration >>> stuff has never gotten beyond horrible-to-do. >>> >>> All-in-all, a really bad outcome which is still >>> a PITA a dozen years later. >>> >>> As OAuth AD I will need *serious* convincing that >>> there is a need to provide two ways to do the same >>> thing. I doubt it'll be possible to convince me, >>> in fact, so if you wanna try, you'll need to start >>> by saying that they are not in fact two ways to do >>> the same thing:-) >>> >>> S. >>> >>> PS: This discussion needs to also involve the Apps >>> area, so I've cc'd that list. >>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
